Scrip for DBA's?

[edski]

Found this!

[reho33]

I used to work in the printing business and I think that we could use Cranes paper at 25% rag content. It is illegal to get the same paper that US currency is printed on but 25% is close. What I don't understand is if companies make metal tokens for certain applications why can't they make scrip that is used for certain applications. I mean I would like to have a 100 dollar bill on hand to load up my slot machine with credits but daily expenses would eat that up in a heart beat. I also understand that the tickets could be printed but no back end acct. software exists for home users to read the ticket back and credit the machine. But the barcode generates numbers and those numbers could be read by certain logic to correspond to a credit amount. One thing that life has taught me: if people as a whole contribute, the overall product can be better than commercial products.(look at Linux Ubantu). Maybe we could invent something that casinos could use and if it was widespread enough, SAS might be a thing of the past. This is an example of how "people power" really works.

[knagl]

Just throwing this out there for whatever it's worth... Casino Royale in Las Vegas has a bank of promotional machines (anyone who visits gets "$50 in free slot play!").  They're IGT S-2000s, and they take scrip tickets via their dollar bill acceptors to credit them up.  From what I remember, they have $50 and $100 tickets that almost appeared to have a magnetic stripe built into the ticket, which was the same size as a dollar bill.

[StatFreak]

If we're making our own bill and having software to read it developed, why think inside the box? We could create a $500 or $1000 bill instead of a $100. Of course, that might create too many credits for some people's setups. Just a thought.

[jay]

My suggested format would be to simply divide the end of the bill into 24 fields that are either on or off leaving the rest of the note to have whatever other info, colors  logos etc that we want.

ie:
-------------------------------------------------------------------------------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|                                                                                                                       |    
|                                                                                                                       |          
|                                                                                                                       |    
 
If we simply used each of the  3 x 8 bit bytes to specify a value between 0 & 255 (256 choices - simple binary)
We could represent any value we wanted on the bill by simply multiplying the 3 numbers together to represent a value.
256 x 256 x 256 = 16,777,216 combinations.

The next decision would be how to use this number. The simplist would be to make this represent credits.
However that means when I put a Credit ticket of 500 into my dollar slot it would worth 500 dollars but if I put it in my penny slot it would be worth 5 dollars.
Not very equitable and certainly if one was to mint their own currency they would need to know the specific denomination of thei machines they were used on to be able to make this even seem right. As soon as you have two different denomiations the minting rationalle goes out the window.

My next thought would be to do this in pennies, but that would make the largest ticket only be worth 16K, enough for a W2G but if smeone is running $100 tokens it might be a bit limiting.

Finally to denote it in dollars seems to offer the most balance. This would allow a ticket of $167,772.16

Deffering to OP-Bells intimate knowlege of the DBVs perhaps the end of the ticket might not be the best placement but the point of my post was to come up with a very basic, easily printed universal note for home use vs worrying about any kind of special paper, security features etc that would tie us to an expensive and possibly scarce source.

[dpalmi]

The biggest hurdle is going to be getting the machine to accept something other than currency.  Until you get that figured out - you might as well not even worry about what kind of bill or ticket you want to create....

From what I can tell - there are 2 options.

1.  Modify the acceptors EPROM to include a fake bill as if it was a real bill.  This is the hardest way if you ask me.  Someone would have to figure out how to modify the existing code in the eprom to include these new types of bills.  And you would have to do it for multiple bills, multiple brands of acceptors and multiple versions of the code.  You would also have to update this modified code when new versions of the eproms are released to support new bills that come out.

2.  Create a backend TITO like system that is able to take a validation code from a barcoded ticket that is read into the machine.  I think this makes the most sense (not that I think it is going to be easy).  The front end of this is already done for us.  Machines already have the power to read the barcode and pass it to a server for validation.  Wouldn't matter what brand of acceptor is in the machine of even what kind of machine it is.

So - where to start.  Seems like you have to figure out how to connect a machine to a network, get it to talk to a server and use some monitoring software to watch what the machine says to the server when a ticket is inserted into the machine.

Anybody know how to connect a machine to a network??

Dan #2

[edski]

The DBV does not do credits.
When you set up a machine for a BV, you specify what the machine denomination is.
The machine translates the BV amount into credits.

Ed

[edski]

The biggest hurdle is going to be getting the machine to accept something other than currency.  Until you get that figured out - you might as well not even worry about what kind of bill or ticket you want to create....

From what I can tell - there are 2 options.

1.  Modify the acceptors EPROM to include a fake bill as if it was a real bill.  This is the hardest way if you ask me.  Someone would have to figure out how to modify the existing code in the eprom to include these new types of bills.  And you would have to do it for multiple bills, multiple brands of acceptors and multiple versions of the code.  You would also have to update this modified code when new versions of the eproms are released to support new bills that come out.

2.  Create a backend TITO like system that is able to take a validation code from a barcoded ticket that is read into the machine.  I think this makes the most sense (not that I think it is going to be easy).  The front end of this is already done for us.  Machines already have the power to read the barcode and pass it to a server for validation.  Wouldn't matter what brand of acceptor is in the machine of even what kind of machine it is.

So - where to start.  Seems like you have to figure out how to connect a machine to a network, get it to talk to a server and use some monitoring software to watch what the machine says to the server when a ticket is inserted into the machine.

Anybody know how to connect a machine to a network??

Dan #2

Op-Bell has offered to rewrite the eprom code.
That's where we're at!

Ed

[Neonkiss]

Deja vu!

I've already done it and posted my findings about a year ago.  Check out this thread...

http://newlifegames.net/nlg/index.php?topic=1009.msg21846#msg21846

Just a quick review - the bardcode is the validation # on the ticket.  So for the ticket below, the barcode equals "000000000098211498" - no dollar amounts....sorry!

Dan #2

Dan, Thanks. I owe you some Donuts.
I guess I was wrong. Too bad this did not hold true.
Any chance in changing that software in the thermal printer to print a bar code that corresponds to the ticket value?
Then have the DBV read  the bar code and convert it back to credits.
If were changing software maybe we need to change it on both ends.

[dpalmi]

Op-Bell has offered to rewrite the eprom code.
That's where we're at!

Oh - opps.....cool!

 

Dan #2

[StatFreak]

My suggested format would be to simply divide the end of the bill into 24 fields that are either on or off leaving the rest of the note to have whatever other info, colors  logos etc that we want.

ie:
-------------------------------------------------------------------------------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|                                                                                                                       |    
|                                                                                                                       |          
|                                                                                                                       |    
 
If we simply used each of the  3 x 8 bit bytes to specify a value between 0 & 255 (256 choices - simple binary)
We could represent any value we wanted on the bill by simply multiplying the 3 numbers together to represent a value.
256 x 256 x 256 = 16,777,216 combinations.

The next decision would be how to use this number. The simplist would be to make this represent credits.
However that means when I put a Credit ticket of 500 into my dollar slot it would worth 500 dollars but if I put it in my penny slot it would be worth 5 dollars.
Not very equitable and certainly if one was to mint their own currency they would need to know the specific denomination of thei machines they were used on to be able to make this even seem right. As soon as you have two different denomiations the minting rationalle goes out the window.

My next thought would be to do this in pennies, but that would make the largest ticket only be worth 16K, enough for a W2G but if smeone is running $100 tokens it might be a bit limiting.

Finally to denote it in dollars seems to offer the most balance. This would allow a ticket of $167,772.16

Deffering to OP-Bells intimate knowlege of the DBVs perhaps the end of the ticket might not be the best placement but the point of my post was to come up with a very basic, easily printed universal note for home use vs worrying about any kind of special paper, security features etc that would tie us to an expensive and possibly scarce source.

<EDIT> Lots of people posted while I was tying -- so I've added Jay's post as a quote since I'm no longer right after him.

I may be wrong here Jay, but I think that in order to have a flexible system whereby the machine can read any type of code and interpret a dynamic value would require a dbv with the special hardware capable of reading bar code-style information: i.e., capable of reading tickets.

In such a case, I'm still not clear why the standard bar code (3 of 9 or whatever is being used in the S2000 ticket printers) can't simply be used to represent a decimal number of pennies instead of a serial number? That string of numbers is long enough to represent millions of dollars in pennies if simply read as a single value, no binary required, since a bar code would allow the representation of all digits 0-9. No serial number record to look up in some database -- just a straight forward number that represents a dollar figure in integer form.

On the other hand, if we get back to the primary focus of the discussion at hand, which is to create a user-defined bill for a normal dbv that does not have the extra hardware, i.e., can't read bar codes, I do not believe that my above suggestion, nor Jay's ideas would work; we would be designing a fixed pattern (which, in essence, could be anything at all) that would be hard-coded into the validator's software to be interpreted as a fixed value, just as currency of a specific denomination is valuated.

This brings us back to where we were: creating a single piece of paper ("bill") that has specific markings (any unique set of ink markings along a horizontal line at some specific vertical point along the length of the paper unit, just as is done with a dollar bill) and a specific IR paper signature, that will be read by custom software burned onto the chip/flash of the dbv and translated into a fixed dollar value to be sent to the slot.

We use the KISS method and create a very simple ink pattern (e.g., something that looks like a simple bar code), assign a desirable fixed value (e.g., $100 or $1000), and use universally available paper stock (e.g., HP Laserjet 24lb 92bright paper) to come up with one "bill" and a matching "chip" that everyone can use and print at home on their own printer.


What can get confusing here is that the phony "bar code" that we would be using here would not be the same as a true bar code. The machine's standard dbv (including one on an S+) would not be capable of reading different combinations of bar code "patterns" and interpreting a value, but would rather be reading ONE specific phony "bar code-style" pattern that the custom software would then interpret as being a $100 or $1000 bill.

<ADD> It looks like I'm on the same page as Op-Bell at this point.  

[jay]

Using a series of dots along the bill is about the same thoughts I had.
Using the dot method is no different than what I am suggesting.
My thoughts were just to make if flexible to represent any value.

[StatFreak]

Using a series of dots along the bill is about the same thoughts I had.
Using the dot method is no different than what I am suggesting.
My thoughts were just to make if flexible to represent any value.

Well, Op-Bell can correct me if I'm wrong, but if it's going to work in dbv's as a unit of currency rather than a ticket, then the physical limitations of the validators will preclude making them flexible. And, as I understand it, making them flexible instead would exclude any dbv that could not read tickets, and would require a quantum level increase of difficulty in designing the software, as the simple model would only require the insertion of static data to represent the input read from our new bill and the static value to output in pulses to the slot upon reading that static data, whilst creating a flexible system would require writing a completely new piece of software to run the dbv since their extant software is not currently designed to interpret bar code values directly in any way.

[jay]

I understand where you are going with this. You are saying that there are set images vs interpertaive code.
RATS.

So lets work this backwards what changes between a DBV200 that can and those that cant ? is it another board, different head etc ?
Would the entire WBA series be able to ? or were there versions that could not.

[Jeff]

Hmm, I've been reading this, and I find it very interesting, but the bottom line is this.
As long as there is no watch dog watching the DBV, and or integrity checks, and providing OP-Bell
is a decent enough coder, I don't see any problem at all. BTW, when debugging, reversing, or coding at the machine level
it's all binary.

[reho33]

So the 4 options are these:

1) Reverse engineer the code for DBV's to accept scrip.
2)Use Zimababwe currency as it is dirt cheap and make the DBV recognize it or
3)Continue on the way we are doing : using US currency in the slot and promptly removing it from the cash can.
4)Using a card reader/writer to add credits via a mag strip card forgetting about the DBA altogether.
Hmmmmmmmmmmm................................

[Op-Bell]

This is a more complicated matter than many of you understand. To start with, if we restrict it just to JCM and the models people use on NLG, there are five different validators that would all need software - DBV145, DBV200m WBA10/11, WBA12/13 and UBA. If we include Canadian head models, there are seven of them.

Then there are four different interface types in common use - ID023, ID024 Netplex, ID044 and ID003. Leave aside for the minute that the first two are claimed as proprietary by IGT, who would have to give permission for ID023 and ID024 to be made and may want to be paid for it. That means there are 28 different firmwares that have to be made. This is a lot more complicated than (say) hacking a new pay table into a game ROM. The validator firmware is a closely guarded trade secret because it's a financial instrument of interest to regulators, and getting it compromised could mean getting the company's validators banned from many jurisdictions. I'm not saying it can't be done, but I'm not going to do it. The only people who can make new firmware for JCM validators are JCM.

A new currency firmware is made by loading up special software in a head and feeding representative samples of currency, recording the data patterns that come out, then working these patterns down into recognition tables and compiling them into the BV firmware. This takes some time, say a man-day. If it has to work with both NLG-scrip and Edski-scrip, more work is needed to make sure it ignores the differences, which is why I'm in favor of one common design made by a commercial printer who knows what he's doing. In order to get the firmware made, you have to offer enough money to a stone-faced accountant to convince him he'd make more money by doing this job for you than he would by having his man work on something else.

That's why, in my opinion, this is a commercial project for a dealer or a consortium of dealers, not a home-made hack.

[jay]

As long as you have a  compiler sutible for the processor you can pretty much work in any language.
C, and assembler typically creates more efficent code than that of other languages.
To work from scratch you also need intimate knowledge of the hardware so you know what registers to load etc.

What we are talking about is more than simply dumping the contents of the eproms into a hex editor and shifting some bytes around.
OpBell has a long history with this hardware and software. 

[Jeff]

So you would be decompiling adding in your snip it of code and then recompiling.
BTW, I said a Debugger such as IDA or Olly not a hex editor. Two entirely different things.

[reho33]

Totally understand what has been said so far. OK well if someone wants to take a stab at it then do so and report your findings here. If not, well I guess I can get used to the DBA though I do not have room in my S+ for one. But now for any machine that I buy in the future that may have one I guess I will just use it.

[a69mopar]

  We don't need to do Canadian heads, as they cost to much to use anyway.  As for myself, only one bill (100 slot bucks) would be fine with me, made commercially sounds fine too, although, I wonder how much that would cost ber 1000 bills.  ID003 covers a few manufacturers, and it alone would be awesome to get done. as I previously mentioned, wba 12/13 would be great.  .  K+ op.

Thanks,
Wayne

[jdkmunch]

It's a great idea to have the tickets validated - but I thought once again this information was proprietary to IGT. 

SAS? 

I think I remember from another thread that all other slot manufactures must lease this from IGT in order to make TITO work for their machines.

 

[rickhunter]

Why not just tokenize the machine.  Set the token value to 99 credits (max value on an S+).  So you only have to put 1 coin in for ever 99 credits.  No bills, no validators, and no currency in/out.   I do this with my WMS video machine, putting in 300 coins to spin the reels once is out of hand, even a $100 bill goes fast when you are betting say $15.00 per spin. So I set my token value to $2,000.00.  One token and I can play for a while.

[reho33]

What are the menu steps to set the credit value?

[rickhunter]

You need a token compatible game chip and set chip.  See this thread for all the information.

http://newlifegames.net/nlg/index.php?topic=4242.0