Trying to design a coinless system

[SLOTMAN]

In my venture to make playing with my machines more exciting I am trying to devise a "coinless" system.  I am pretty well versed in microcontrollers and C programming.  Since my days of using a scope are long gone and I dont have access to one anymore I am calling to the NLG community to help me with some stuff on the coin comparitors.

What I want to devise is a computer controlled cashless system.  As far fetched as this sounds it isnt that hard.  What I need to know is the data from the comparitor and the optics or even the bill acceptor.

What protocol does the DBV use to register the machine that a bill has been accepted and what value.  Is it Pulse Width Modulation?  Is it Hex?  Is it ASCII?

Even if I take the easier route and go toward bypassing the coin mech on the same machine lets assume there is a CC-16.  About as basic as you get.  I know on a 5500 the CC-16 sends a signal first then a specific time the coin optics register.  If I knew what type of signal I could emulate it with a microcontroller.  I would be able to build a simple Java applet to add credits to machines.  If there is somone out there who can help me I promise to make all my progress and finding public to the whole community.

If this works as planned the cost per machine shouldnt be much more than around $10.00 so it is very cost effective.



Any information or feedback would be greatly appreciated.

[reho33]

Slotsdirect.com has Bally "free play" machines. You just push a button to add credits and cashout works with nothing dispensed from the machine at all. If you are trying to do something like that, you might like to know that a seperate board was added to these machines to make them act that way. How they did it is a secret that they might not be willing to give up. I know that there have been threads on it so do a search and look around.

[SLOTMAN]

The seperate board will be a microcontroller that I program in C.  I just need to know exactly what the pulse is from the acceptor or optics and I can emulate that with a microcontroller.  Short of having a scope I just have to go off what others may know.

[stayouttadabunker]

Quote[I would be able to build a simple Java applet to add credits to machines.]End Quote

Where on a machine would this be installed to?
Have you ever opened up an SP chip on a S+ board to see what was in it?
You might see some programming in there that might interest you very much!

[a69mopar]

If you manage to fake out the BV then it should work on other machines with the same protocol.  For an S6000, it's ID003, the same as Sigma, Atronic, and others.  The concept is great, press a button and it thinks it accepted a $100 bill.
Thanks,
Wayne

[SLOTMAN]

Faking out the validator is going to be very complicated, I admit that.  Faking out a simple set of optics will be a easy task.  The only problem would having to make sure the machine will accept over the max bet amount or you may throw it in to tilt because it would look like a coin is going through even though the coin mech should be diverting.

If anyone has tested the optics I just need to know how many milisecond pulse it is and I can go from there.  I have all machines to work with so machine type isnt a problem.

[StatFreak]

For the S-Plus you can use an SP chip with Montana credits to allow the machine to accept coins beyond the max bet. For other platforms, YMMV.

The timing of the pulse was discussed to some degree here.

[SLOTMAN]

StatFreak, thanks for your reply.  You have answered one piece of the puzzle which is a big help.  What I have gathered is the coin mech puts out a 16ms pulse +/- 4ms.  That is great.  My microcontroller can do that without any problem.  I will setup a test station and test the theory.

The next step will be the time delay pause before the coin optics actually see the coin and then the pulse that the coin optics put out.  When I have those two variables I can program the microcontroller to emulate it.

Ultimately I would like to know what the bill validator puts out as emulating that would be a lot more exciting.

[SAT (aka GANDHI)]

Hi

Looks like fun what you're trying to do...  I see you have already the delays info, so all I can add is a piece of code I wrote some time ago to perform the task of adding credits to slots machines working with CC-62 and CC-16 acceptors.  You are free to use it as reference.

As you said, the goal of adding credits through the coin signals can be achieved easily with any of the low-range micro-controllers out there...  The code below was the first try I made using the good-old PIC16F84, later for the final version I adapted it for the smaller PIC12F508/509 in order to use the built in oscillator instead of a cristal and capacitors arrange.

Some notes of my project:

- Since I made my board to work for both CC-62 and CC-16 comparitors I had to add two sense outputs in my code to emulate successfully the CC-62 behavior.  Remember the CC-62 works by sending two open-collector pulses to the slot machine in a sequence.  The COIL pulse first, followed by the SENSE pulse with a gap between both that represents the time when the coin is traveling from the coils to the led sensor.  If that sequence isn't respected the machine will go into TILT (coin jam) state.  The CC-16 is simpler because it only sends the SENSE pulse, so in that connector I routed only one of my outputs.

- For some reason when I programmed the micro to work with the delays of the data-sheets I had the slot machine falling into Coin-JAM state.  I fixed it reducing the gap between delays to a minimum, even less than what the papers said.  Not sure if it was a matter related to the machine I was working with or something else... I just tell you how I solved it.

- At the end I unified my three delays because I saw they worked being the same one (Coil-Travel-Sense) . It was easier in the code and I was also looking to add credits as fast as possible only to find out at the end that the credits signals in the Aristocrats are buffered, so it doesn't matter how fast I programmed my micro, the credits will add at the machine's speed 

- The final delay I used in the 508/509 version was 3 milliseconds.  It worked lovely 

It isn't written in C, but hope it's of help for your work.

Code:

;CC-62-beta.asm for pic-16f84.

;Written to test coin acceptance circuitry of slot machines by emulating coin acceptance signals.

;The program sets "porta" of microcontroller as "input" and "portb" as "output".

;Timer prescaler is set to "/256" to give timing pulses of "1/32" of a second using a 32,768 Khz cristal.

;Delays of coin traveling through the coin comparitor are already added to the "subroutine" section and
;they are preliminary, they need to be adjusted in the workbench.

;This program was written for test only purpose!!

;Andres D'Andrea



;*****************************************************************************

;equates section

tmr0		equ		1					;means "tmr0" is file 1
status	equ		3					;means "status" is file 3
porta		equ		5					;means "porta" is file 5
portb		equ		6					;means "portb" is file 6
trisa		equ		85h					;means "trisa" (the "porta" I/O selection) is file 85h
trisb		equ		86h					;means "trisa" (the "portb" I/O selection) is file 85h
option_r	equ		81h					;means the "option" register is file 81h
zerobit	equ		2					;means "zerobit" is bit 2
count	equ		0ch					;means "count" is file 0ch

;*****************************************************************************

list		p=16f84
org			0
goto		start

;*****************************************************************************

;configuration bits
__config h'3ff0'							;selects LP oscillator, WDT off, PUT on (Power On Timer), code protection
									;disabled

;*****************************************************************************

;subroutine section

;Coil Sense delay

sense1	clrf		tmr0				;start timer0
loopa		movf		tmr0,w			;read tmr0 into working register
		sublw		.5				;time - 5
		btfss		status,zerobit		;check time - working register = 0
		goto		loopa				;time is not 0, so do it again
		retlw		0				;time is 5, return to the last point in program

;Travel between sensors delay

travel		clrf		tmr0				
loopb		movf		tmr0,w
		sublw		.3
		btfss		status,zerobit
		goto		loopb
		retlw		0


;Led Sense delay

sense2	clrf		tmr0				
loopc		movf		tmr0,w				
		sublw		.4					
		btfss		status,zerobit		
		goto		loopc				
		retlw		0


;*****************************************************************************

;configuration section

start		bsf		status,5			;turns to bank 1
		movlw	b'00011111'		;5 bits of "porta" are inputs
		movwf	trisa
		
		movlw	b'00000000'
		movwf	trisb				;"portb" is all output
		
		movlw	b'00000111'		;to set the prescaler at /256
		movwf	option_r			;timer is now 1/32 of a second using the 32.768 Khz cristal
			
		bcf	status,5			;return to bank0
		clrf	porta				;clears "porta"
		clrf	portb				;clears "portb"

;*****************************************************************************

;Beginning of program:		

;Button x1: add one credit each time pressed

x1			btfsc	porta,0			;check if switch is pressed
			goto	x10				;switch wasn't pressed, check again!

			
			bsf	portb,0			;switch was pressed, send the first pulse
			call	sense1			;wait
			bcf	portb,0			;clear the first pulse
			call	travel				;wait
	
			bsf	portb,1			;start sending the second pulse
			call	sense2			;wait
			bcf	portb,1			;clear the second pulse
			call	travel				;wait


;Button x10: add 10 credits each time pressed

x10			btfsc	porta,1			;check if switch is pressed
			goto	x1				;switch wasn't pressed, check again!

			movlw	.10			;load 10 into W
			movwf	count		;load 10 into "count"


repeat		bsf		portb,0		;switch was pressed, send the first pulse
			call	sense1			;wait
			bcf	portb,0			;clear the first pulse
			call	travel				;wait
	
			bsf	portb,1			;start sending the second pulse
			call	sense2			;wait
			bcf	portb,1			;clear the second pulse
			call	travel				;wait

			decfsz	count		;count - 1, skip if cero
			goto	repeat
			
			goto	x1


END

BTW:  Happy new year !!!!

[StatFreak]

Nice SAT. 

Just a thought: I would have given the sub code in routine X1 a name and called it ten times from routine "repeat" with a simple loop instead of duplicating the X1 code in routine "repeat".   Or modify "repeat" so that it can be called from X1 and X10 and delete the extra code in X1...

[SAT (aka GANDHI)]

Nice SAT.  

Just a thought: I would have called routine X1 ten times from routine "repeat" with a simple loop instead of duplicating the X1 code in routine "repeat".

That's right Stat !!!   Just wanted to time and see who was the first to point that out !!!    My watch reads 11:06:5342  .....  Too long but you won the prize anyways  

Now seriously:  Even when I've been reading about these things for a while I consider myself a TOTAL NEWBIE regarding microcontrollers and its programming.  The true is that when I was developing this little thing I was reading a book called "PIC in Practice - Project Based approach" by D.W. Smith.

I recommend it for anyone trying to get into the beautiful world of micros cause the explanations are extremely simple and well done in this book.  In fact, for this project I was putting in practice the things I was reading and that's why you see that kind of (dumb) routines in my code...  I would call this book PIC for Dummies hehehehe....  For me is the best, I really like how the author make all his points.

Thanks for the advice and best regards.

----> ADDed

You know... recalling a little bit I remember I tried to do that (simplifying the frigging code) when finishing the project on the 508/509 but I couldn't because the 508/509 has a stack of two levels and the way I was coding (calling subroutines every time I wanted to do something) didn't appear to work with such a small stack... [any suggestions/inputs regarding this subject will be appreciated]

The fact is that I needed the board up and running quickly so I preferred to expend some more lines of code instead of wasting time testing more options.....

Ohhhhh....    god helps those like me slaves of TIME   

[SLOTMAN]

Sat, Kudos to you.  This is exactly what I am looking for.  The language is a little different but in the microcontroller world I am sure I can make it work. 

Now, part one of the puzzle is mostly solved.  I will bench test soon.  The next step is to take a value and program it to a simple magnetic strip card.  All it needs to be is a number and nothing else.  Pretty simple but here is the ultimate goal.  Card has a value which can either be preloaded or come from a hopper pulse (step 3).  That value is read and signals the controller to amount whatever amount is on the card in to credits (erasing it off the card is a different story) since the cards would be passive in a sense.

If this works I will share everything with the NLG community.

[jay]

I would think that the main stream approach might be to use the SAS interface and put credits on the machine through ETF.
I have heard that there is a SAS manual floating around. We could then use this either with a swipe card system you suggested or through the voucher system on the DBVs

[SLOTMAN]

I would have to assume that the EFT system is as heavily encrypted and guarded as much as bank EFT's.  I may be wrong but I would assume if someone was able to tap in to the network they could credit themselves a whole bunch of money.

Sat:  Would you happen to remember which pins you used for the coin mech and the coin optic?  I have attached a picture of the 16X84

[SAT (aka GANDHI)]

I would have to assume that the EFT system is as heavily encrypted and guarded as much as bank EFT's.  I may be wrong but I would assume if someone was able to tap in to the network they could credit themselves a whole bunch of money.

Sat:  Would you happen to remember which pins you used for the coin mech and the coin optic?  I have attached a picture of the 16X84

Not sure if the EFT is heavily encrypted as you suggest... I believe that knowing which SAS commands to send and having the proper interface with a SAS enabled machine that can be done as Jay pointed [Of course: It's easier to say it than to DO IT !!]

However, I'm interested in what you suggested previously:  adding credits through the bills line instead of the coins like I did....   I tell you that because the problem of adding credits through the coin line is that they have to be added serially... If the adding signal is buffered like it's in Aristocrats the adding process is painfully slow.  Using the bills line would be better but my knowledge about programming micros doesn't go so far (yet  )

Are you able to build an emulator of a bill acceptor based on a PIC? 

Regarding your questions:  I used RB0 as "First Pulse" (coils) and RB1 as "Second Pulse" (optics).  Remember that both pulses are required in CC-62 or later models alike.

[jay]

The reason I suggested SAS is that it works universally across all of the major platforms.

I know coin comparitors are pretty universal but the optics may be a bit more proprietary for each platform and as such bypassing the interface may involve a bit more interfacing.

We know that the bill validators use different IDs 22/23 for the S+,  24 for S2000 and I suspect it has a bunch to do with timing and possibly sequencing. I am sure once you figure them out it would be easy enough to switch between them however it is still machine specific.

From what I know about SAS is that it appears to be a RS422 interface to each slot.  EFT being a command does not appear to be any more encypted than the rest of the SAS protocol.
I think its a 2 or 3 wire interface.

[SLOTMAN]

Figuring out what the protocol is for each item is the hard part.  If I had my scope still I would narrow it down.

SAT:  Good point on the buffering, unless the machines were set for tokenization it could be a painfull time for all the credits to add up.  Tokenization being unrealistic since it is machine dependent and not always possible.

JAY:  The RS422 protocol is sometimes used in a QUASI form which is 4 wires.  I have to admit that as far as EFT and SAS I am totally lost.

So where that leads me is to emulating the bill acceptor as to make the credits a quicker process (Thanks SAT for the input).  I will try to figure out if it is just a pulse sequence.  The problem there is it isnt just putting the acceptor on the bench and checking.  The machine has to communicate with the acceptor to tell it that it is ready to accept.  So that is the first attack. 

If there is any other insight I would love to hear it.

[SAT (aka GANDHI)]

If I had my scope still I would narrow it down.

I think using a scope (oscilloscope right?) would be the hard way to understand any protocol lol...

So where that leads me is to emulating the bill acceptor as to make the credits a quicker process (Thanks SAT for the input).  I will try to figure out if it is just a pulse sequence.  The problem there is it isnt just putting the acceptor on the bench and checking.  The machine has to communicate with the acceptor to tell it that it is ready to accept.  So that is the first attack. 

If there is any other insight I would love to hear it.

I'll tell you what I would do if I would have time enough, because believe me:  this is a time-consuming task!!!  :

Through lots of readings, explanations of OP-Bell and other savvy friends I've understood that the bill acceptors are in constant communication with slot machines, something known as "Polling" in electronic communications.

The machine is constantly polling (asking) the BV to know its state.... Op-Bell said the other day the frequency was about 200ms, so each 200ms the machine sends a row of serial pulses that means "what are you up to now".

At that point the BV has to respond with other row of serial pulses what could mean some of the possible states: "Idle" (nobody has put a bill in the BV yet), or "accepting", "stacking", "rejecting" etc, etc, etc...  Each question made by the machine is followed by an acknowledge and answer of the BV.

All the words enclosed in ""  in this message represents commands that belongs to the serial protocol used by bill acceptors.  Those messages are expressed electronically in form of serial pulses, and digitally in form of hex numbers.

Those messages has a format, a way to check if messages are OK, and they follow a sequence. 

For me that is a protocol.  The monster I would try to beat.

Instead of connecting the BV to a slot machine, I would connect it to my laptop using the harness and software for that and then I would use any of the sniffers (serial port monitors) available in the internet to check "WHAT THE HECK" is my computer talking to my BV and vice-versa   lol...... 

Some suggestions:

http://www.serial-port-monitor.com/

http://www.kmint21.com/serial-port-monitor/

http://www.freedownloadmanager.org/downloads/serial_port_sniffer_software/


I'm talking you about understanding the protocol starting from the end.  A task comparable to reading a book written in a language you don't know,  starting from the last page to the first one,  and the book being upside down

Some people call it reverse engineering.

Are you sure you want to do that?

[SLOTMAN]

SAT: Its cold, I am house bound until about March so I have a lot of time on my hands.  I have found that some protocols use pulse data
which is a good begining.  Is there any post on here that shows a homemade cable to talk to the DBV as I do have the software (thank you JCM website).  I assume it is a DB-9??  I have a stash of cables that I would like to cut up and use to talk to the dbv.
Believe me, I know this is a MAJOR TASK but the only thing lost would be time.

001 DBV/EBA/IBA Parallel Code Interface IGCA
002 WBA/DBV Pulse Interface Various
002/003 WBA/DBV Pulse / Serial Various
003 WBA  JCM Standard; bi-directional serial interface All
003B WBA Standard ID-003 with enhanced "B" interface for barcode instruments.  Bally Systems. Harrah's Corporate
003WS WBA ***For WMS Games Only*** WMS
004/Bar DBV ID-004 with a few extra codes included for barcode ticket data passage. CDS, Amtote
011 DBV Bill acceptor must be reset in order to intialize Sigma
015 DBV Bi-directional serial interface, includes bar code messaging Sigma
022 DBV Measured pulse interface; defined by IGT IGT only
022/023 WBA/DBV Measured pulse interface; defined by IGT IGT only
023 DBV Similar to ID-022 IGT only
024 WBA/DBV Bi-directional interface designed by IGT; also known as "netplex" IGT only
033 TSP-02 SII compatible printer protocol Bally, Konami etc.
042 DBV Pulse mode only Leisure Entertainment
044 DBV Includes both pulse and 1-direction serial Bally (pre-2K), Williams, and others
044P DBV Interface designed to be backwards compatible with Bally Games  Bally
044P/045P DBV   Bally
045 DBV Contains a stack signal and messaging included to support barcoding  Bally (pre 2K)
045P DBV Same as ID-045 with additional messaging Bally
045W DBV Requires stack signal for coupons only Williams
0C3 WBA Bi-directional serial interface designed several years ago  Aristocrat
0D3 DBV-301 MDB Vending customers
Enhanced AD-02 AD-02 Enhanced Interface. Source Technology, others
MDB DBV-301 MDB (Not designated ID-0D3 because this is not manufactured by JCM)  Vending customers
Standard AD-02 Standard AD-02 interface EMN8

[SAT (aka GANDHI)]

Don't have the harness nor the schematics, but there you can download the DBV-200 manual with all the part numbers and the equipment needed to link the laptop to your BV.

http://www.jcmglobal.com/Libraries/Product_Manuals/DBV-200.sflb.ashx

Hope it helps.

[SLOTMAN]

SAT and JAY, thank you very much for the input.  Now I need to get working on it.  I will keep everyone posted on the progress.  I am starting with the coin mech bypass first.  That is a simple pulse timing so it will be very easy to do.

There again, I believe in sharing so I will keep everyone posted.

[SAT (aka GANDHI)]

 



 


Keep us posted