Isn't there a simple way to hook up an S+ to a Desktop?

[stayouttadabunker]

I got the CDS controller last year from April for about 35 bucks, I had got it going briefly but it was so complicated at that time I put it in a box for the winter.
I recently picked up a couple of displays fairly cheap, so I thought I'd give it another shot.
The controller is directly hooked up to my computer via a serial cable which is only using 3 wires.
Other wires (located in a separate serial cable) goes from the controller to the the S+'s motherboard outputs at the J11 header.
Since I have the Mikohns using the J11 header, I made an adapter so I can basically "plug-n-play" (so I can use both systems at the same time).
Each S+ needs 3 wires (ground wire,Address wire,SAS wire). So the harness is really simple.
You program machine addresses to the controller,then the machines SAS spits out all the data back to the controller.
With yet another serial cable, the controller "talks" to the displays and everything is pre-calculated and the displayed onto my desktop.   

Tomorow, I'll try to get the Prosolo displays up and running!

[kenokarz]

this could be the 1st step in to the ticket in on the b/v and have the machine read the ticket printed from that machine,  
neat video,   thanks

[stayouttadabunker]

Jay,
This might be a way to get to the video>>
Go to youtube.com and under "search', type in:

"S+'s hooked up to a home computer."

These are capable of hooking up to a [BALLY MASTERCOM 250 CARD READER CONTROLLER] too....
April has them for 25 bucks with the software too!

I'm having a ball with this stuff

[stayouttadabunker]

this could be the 1st step in to the ticket in on the b/v and have the machine read the ticket printed from that machine,  
neat video,   thanks

Exactly what I'm trying to accomplish...I already have a ticket printer hooked up to my S+...
What I need to do now,  is flash the DBV eprom with pictures of the tickets that come out of the printer so the DBV will accept it...
have the DBV lose various seeking properties such as magetic and size....
Come to think of it, the bulk tickets we got a few weeks ago are exactly the same size as U.S. bills,.....hmm...
It can't be THAT hard , huh?

My question now would be, which S+ DBV has flashable eproms? 
I need to rip apart a DBV chip and insert my own pictures

[stayouttadabunker]

Are barcodes printed out on real tickets? Now I'm thinking barcode reading....arghhh!
The TI-TO technology must be based on these barcodes printing to make the acceptor "read" a tickets  "value" I would think...and they probably don't have magnetic reading abilities either.
Anybody got a working TITO on a home machine? I'll buy it!

[dpalmi]

Hello!

Depends on what you mean by working...I have an IGT S2000 that I can print valid TITO tickets out when I cash out - but the machine won't take them back in.  If this is what you are interested in - what do you want to know?  I'd be glad to help.  Yes - when you print a cash out ticket, it has a barcode on it.  The barcode represents a "Validation" number.  I don't believe the number itself has anything to do with the value of the ticket.  In the casino world, when you print a ticket - the machine sends a central server that number with the value/etc.  Then when you try to use the ticket, whatever device reads the ticket verifies it has a good number on it and then pulls that info from the central server for the value/etc.  That's how I understand it anyway...what other info do you need?

Dan #2

[SAT (aka GANDHI)]

Hello!

Depends on what you mean by working...I have an IGT S2000 that I can print valid TITO tickets out when I cash out - but the machine won't take them back in.  If this is what you are interested in - what do you want to know?  I'd be glad to help.  Yes - when you print a cash out ticket, it has a barcode on it.  The barcode represents a "Validation" number.  I don't believe the number itself has anything to do with the value of the ticket.  In the casino world, when you print a ticket - the machine sends a central server that number with the value/etc.  Then when you try to use the ticket, whatever device reads the ticket verifies it has a good number on it and then pulls that info from the central server for the value/etc.  That's how I understand it anyway...what other info do you need?

Dan #2

Better explanation impossible.... 

Dan #2:   Now I have nothing to say  !!!!   

[dpalmi]

Here's a picture of one from my machine....

Dan #2

[Ozzy]

As far as I am aware if you don't have the purchased TITO setup from IGT all tickets will produce a bar code of "ZERO" value, althought the ticket number will be printed regrding the number of tickets the machine has generated until a ram clear then it will start at ticket number 1.


cheers


O Z Z Y

[stayouttadabunker]

Awesome info, thanks guys

But which S+ DBV has flash-able proms?

[dpalmi]

Hello all!

Ok - I got out my barcode scanner and scanned the ticket on my computer.  The barcode reads the same # as the validation shows "000000000098211498" <--- I did not type this number in - I scanned the barcode right into this post.  The barcode scanners I have just connect between the keyboard and the computer...so it just emulates typing on the keyboard whatever the barcode has.  So the barcode itself is not just zeros - it is the validation # that shows on the ticket.  Not that any of this helps much...lol....

Dan #2

[StatFreak]

Ozzy, I don't know about professional slot programs, but I do know data and general computing. I would think that the slot would send out the value of the credits assigned to the ticket at the time of its generation, either through the general SAS protocol or through that CDS Prolink device. The slot might not care whether there was a computer on the other end to receive the information, depending on whether the protocol called for two-way verification, and whether such a requirement were activated in the slot. In order for the value of the ticket to be stored, there would need to be a server on the other end connected to or housing a database that would create a record to hold the dollar value along with all of the other important information about the record.

It would also make sense to have the database generate the (unique) ticket ID (recID) and send it to the slot to print on the ticket after verifying the transaction, so a slot with a ticket printer that is not set up with SAS would probably just generate ticket IDs on its own as you say, or perhaps starting from some arbitrary number that could entered during set up. Once properly set up, I would expect the ticket number to be sent to the slot from the database through the communication server. The slot would then print the ticket with the received number.

Of course, I could be completely wrong.


<ADD> dpalmi, that's what I would have expected, since the record ID of the ticket is all that the computer would need, unless they wanted to add some security measures to prevent counterfeiting.   

[stayouttadabunker]

I did a little reading and found out that I could indeed convert a DBV-200...
 into using a re-writeable eeprom with bar code ticket info added to the eeprom.
That way i can stick a ticket directly into a DBV-200 head and get credits on a S+...!
I believe that a TITO and DBV's are nothing more than fancy punchcards that IBM used to use in the 60's...lol
reminds me of the hanging chads in Florida voting terminals...


I am not afraid to rip apart stuff to see what makes it tick....

This would be, in my mind, a great innovation for home S+ owners!

[jay]

Well before you get out the puddy knife to start prying those chips off......

I believe that any item inserted into the bill validator if it is NOT validated by the DBV subsequently makes a query from the central database if it is available.
So presumeably if the ticket had a bar code of 323 - the 323 gets passed to the database, the database returns a lookup of 120credits and subsequently sends it to the slot via EFT (Electronic Funds Transfer). The 323 would then be deleted from the database so the same ticket could not be used again.

The fly in the ointment to what SOB suggests of just plugging stuff in the the DBV200 chip is that there could be 20 million different values and for each to be recognised would take up a lot of space on the dbv200chip. You would be better off storing images of monoply money and then you only deal with 1,5,10,20,50,100,500,1000 (the monopoly currencies). or even better get the database back end.

[MikeC]

Perhaps the thing to do is figure out how to get the system to print the cash value on the ticket (in barcode form) rather than the identification number of the ticket.  Then zap the BV to read barcodes as dollar values and store it as if it came in from EFT (or route it through EFT).  The BV is already reading "dollars" and storing their value as credits, so the path to "store as credits" is probably already in the chip somewhere.  Just find where it reads the barcode and sends to central, and branch  and store the value in the "store as credits" code.

Of course, this would only be useful to home users since ANYONE can print a "ticket" with a barcode that represents a numeric value. 

-MC

[StatFreak]

Perhaps the thing to do is figure out how to get the system to print the cash value on the ticket (in barcode form) rather than the identification number of the ticket.  Then zap the BV to read barcodes as dollar values and store it as if it came in from EFT (or route it through EFT).  The BV is already reading "dollars" and storing their value as credits, so the path to "store as credits" is probably already in the chip somewhere.  Just find where it reads the barcode and sends to central, and branch  and store the value in the "store as credits" code.

Of course, this would only be useful to home users since ANYONE can print a "ticket" with a barcode that represents a numeric value. 

-MC

I think that this would end up being much more problematic than sending the bar code ID to a computer with a database. The DBV doesn't store the dollar bills values as credits. It sends the value of the bill to the machine which, in turn, converts the dollar value to credits. The dbv uses the "room" in the ROM chip to store the digital representation of the visual and magnetic data that it expects to see for each bill: a static "picture", if you will, of what each bill looks like. The dbv200 has to have four images for each denomination -- one for each direction. These are what take up most of the space in the ROM. Mapping one (or four) of these images to a single value representing that the image is worth $50 (for example) takes up almost no space. The dbv ends up sending a single value to the machine to indicate the value of the bill in whole dollars and the machine applies the credit/dollar value (a value stored in its CMOS memory from the SET chip setup in the example of an S+) to determine how many credits to give.


The DBV ROM couldn't possibly store values for every possible bar code. What you would want to do would be to set it up to read each of the 10 bars representing a single digit. It would then have to concatenate the digits read into a dollar/cent value and then transmit that as a single dollar value to the machine. To do that, you would probably have to completely re-code the dbv software, since I doubt very much if it was ever designed to do such a thing.

It would be much easier to serially output the string of numbers read off of the bar code using the established communication protocol and to have the computer handle the transaction on the other end.

Op-Bell, feel free to jump in here and slap me if necessary!

[stayouttadabunker]

I think we need our resident DBV guy to shed some light on this subject  

OP BELL !!!! HELP!!!

[SAT (aka GANDHI)]

I think we need our resident DBV guy to shed some light on this subject  

OP BELL !!!! HELP!!!

For sure!!  OP-BELL is "THE ONE" in this subject... 

I´m reading interesting stuff here, thanks for sharing all your knowledge gentlemen

[jay]

Stat I agree with your speculation that there would be no correlating value of the images stored.

It would be my presumption that the SET chip polls the the firmware checksum so if the DBV becomes altered from the time the casino enables it then it disables the reader functionality. This would be a security feature.

I would then suspect that when the machine is in operation that the DBV upon the successful validation a bill simply returns a value of 0 thru 5 representing each of the 6 bills 1,5,10,20,50,100.
and the slot would then convert this to credits.

- Just to be clear I am just speculating here - but this method would allow the DBV to work with Canadian, Euros, Francs, Pesos (or whatever) and the coding at the slot end would not need to change.

Knowing that a bar code CAN be read... then If the machine was to get a value of something else ofther than the (0 through 5) presumeably the value of the bar code (as why would they waste another register) then the slot would need to pass this value to SAS so it could be externally processed. SAS would then send back the EFT value would be used for credits.

SO if this functionality is already there that means the dis-assembly would be at the slot end not at the DBV/JCM interface. Unless of course you want to change the $1.00 image for a Monopoly buck etc.

Further extrapolating this line of speclation you would then think that you could create a small circuit that would acknowledge the SAS query and replay that value back as a EFT amount. This circuit would require a Rs422 driver and a working knowlege of the SAS protocol to both accurately read the value being sent as well as to forumate the EFT transfer command.

Just my theories.....perhaps someone with some real knowlege would be as kind as to enlighen us....
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

[stayouttadabunker]

I have no knowledge, but I can "lighten" things up a little...
I wonder if Monopoly money works in a Monopoly machine....

[StatFreak]

I have no knowledge, but I can "lighten" things up a little...
I wonder if Monopoly money works in a Monopoly machine....

You could try it in Atlantic City the next time that you're there.. Just tell them that you mistook the stuff for the real thing and that it was left over in your wallet from your last AC conquest (the home of Monopoly™). I'll visit you every month.

[SAT (aka GANDHI)]

...
I wonder if Monopoly money works in a Monopoly machine....

  wow that's a good one....  I bet WMS has released a service notification about that in their support site 

[RBPerrine]

in the back of my S+ book ( 1993 edition) they have some prints on a fiber optics interface module for the SIS system. #754-216-10 Rev C
 the fiber optics board connects to J13 printer jack on the mother board, then loops thru the machines to the DOC using the fiber optics cable.
What's the point of putting this on the printer out.....if you can get all the data from the DuArt at J4?

A while ago in a bunch of junk that I bought....I got some IGT  #754-22030 boards.   The have a TLP504A opto isloator on them and a MAX232CPE....which is a RS 232  serial port chip. It's very similar to the fiber optics board....anyone know what it's for?

[stayouttadabunker]

I have a couple of the 1992 ASSY NO. 7542200 boards...
They both have the MAX232CPE serial port chips on them as well.
On the J2 header, it's a 4-pin
The J82A header is a 6-pin.
Both boards have 5   2-pin jumpers as well...
I'm thinking this board is very similar to the one you're speaking of ?
Click on photo to enlarge and make clearer...>>>

[RBPerrine]

yes  same board.....If you have some of the Pic Microchip books.....you'l find a circuit for the MAX as a bi-directional input/output chip.
So this board  can be your interface from the DuArt or the printer port to your computer.
I don't have anything on it's orginal purpose....
the optic isolator is a Toshiba  quad unit....and you have a couple of smitt triggers for cleaning pulses.