Dongle news and parlour questions.

[daverob]

How's the experiments with the ball counter turning out.

Nothing much to report on it at the moment, I've got a few sensors to evaluate, but I'm concentrating on getting the rev2 dongle code ready for the beta testing at the moment.

Current progress on the rev2 code is...

The dongle now autodetects the smartcard reader and storage of your credit balance on a smartcard is now available in all modes. There's still a few minor bugs to work out with some of the modes. For example, when you're in a credit add mode with a blank smartcard (ie one that's never been used before), the credits read from the card will be FFF and so it will max the card out to 999 credits.

The amount of time the return button has to be held down before credits are added can now be changed in the setup mode. The adjustment range is from 0.5 seconds up to approximately 4 seconds.

The shooter handle can now be disabled when there is no card present in the card reader slot. (This setting has no effect when the smartcard option reader board is not connected).

The setup mode now contains all of the new settings (even though some of them are not fully implemented yet), and can be accessed in several new ways. Gone is the little black setup jumper link, the setup mode is now accessed by holding down both buttons while the pachinko machine is powered up. If you want to disable access to the setup mode, then you can use a jumper link on the expansion connector.

If you have a smartcard reader attached you can also use the new setup mode smartcards. These cards are specially coded to cause the dongle to enter the setup mode whenever they are inserted into the card reader.

When they are used to access the setup mode an additional setting is available, which when enabled will lock the setup mode to the unique serial number of that particular setup mode smartcard. When locked the setup mode cannot be accessed by pressing buttons during power on, or by any other setup mode smartcard.

The display animations have been put into the code and seem to work ok, but they're not linked up to any events yet. I need to make some big changes to the counter routines to integrate them fully.

After this, the next bit of code I'm working on is to make the dongle pay out multiples of 25 balls for one credit, and also make it possible to deduct more than one credit per payout.


BTW. If there are any new features you would like to see in the new versions of the dongle, now is the time to post your requests. I've still got about 20% of the memory available to use on the rev1.1 dongles and loads more on the rev2 dongles, so should be able to fit a few more features in.

[rubberratt]

(being virtuous)

BUT VERY EXCITED

Have the display blink BRIGHTLY (flashing 000) when you run out of credits ?

[daverob]

Have the display blink BRIGHTLY (flashing 000) when you run out of credits ?

The blinking of the credit display wouldn't be too difficult to add, but can't really drive the displays significantly brighter than they already are due to hardware limitations in the pachinko machine.


When I first designed the dongle, I dismantled almost all of my pachinko machines to find out the specs on the LEDs used in the credit displays, and the resistors used to set the display current (and brightness). There's quite a variation between manufacturers, with some choosing conservative settings, and others driving their displays very close to the absolute maximums shown on the LED manufacturers data sheet.

When I added the display brightness adjustments to the setup mode on the dongle, I decided that I should only drive the displays to about 80% brightness (a brightness setting of '9'). This was mainly because there wasn't any real observable increase in brightness over the original maximum of '11' (as it's one brighter, isn't it? It's not ten.), and also so I could be certain that there was no risk of burning out the LEDs.

[rubberratt]

The brightness setting on your dongle, is one of my favs. I know it took a lot of investigation to be able to do this, while maintaining the the proper care and feeding of the LEDs

So I am suggesting to override the dongle brightness setting (I keep mine very low) to the 80% (if it is set lower than that) and blinky display (SWEET)

[daverob]

So I am suggesting to override the dongle brightness setting (I keep mine very low) to the 80% (if it is set lower than that) and blinky display (SWEET)

Been playing around with this concept this morning and think I've got the code figured out to flash the display using an independent brightness setting. I haven't disabled the leading zero blanking routine so it's only flashing ' 0' at the moment, but it does appear to work.

Now I've got a choice of either re-writing the leading zero blanking routine so that it can flash '000' at full brightness, or there is a second option...

The hardware in the pachinko machines means that only one of the three digits is lit at any one time, it only looks like all three are lit because the digits are lit in turn faster than the eye can see, but in reality each digit is only lit for one third of the time. This means that if I leave the display as ' 0' then I could not only light the units digit in it's normal third of the time, but also use the thirds where the hundreds and tens digits would normally be lit to make the units digit even brighter.

Now theoretically this should be safe to set the displays this bright as the original hardware 80% brightness limit was chosen to ensure that there was no risk of damage to the credit displays if the dongle code crashed and got stuck with only one of the three displays lit (which is essentially what we're going to intentionally do here). But I'll have to do some proper testing first. (Don't worry this will be tested on the test rig, so there's no risk of harm to any of my precious pachis).

So what would you prefer, a slightly brighter flashing '000' or a significantly brighter flashing ' 0' ?


In other dongle news...

The smartcard reader is now working correctly in all modes, and no longer comes up with strange credit values in modes that it wasn't originally designed for.

The 'Ball Loan Available' LED settings are now implemented so you can choose if you want the LED next to the credit display to be lit or not, or have it turn off when there's no credit available.


Next task is to try and get the display animation effects integrated into the main code. I'm not sure I'll be able to get these working on the old r1.1 dongles as the animation code comes in at around 200 bytes. This might not sound a lot (especially seeing as this paragraph is more than that!), but it's about 10% of the memory on the old dongles so is quite significant. In comparison the code that allowed the shooter handle to be disabled when there was no card in the smartcard reader only increased the code size by 6 bytes. Though I might rewrite the animation routine so that the data table is stored in the EEPROM rather than in program memory, to see if this reduces the space requirements.

[daverob]

I'm pretty much done with what I would consider to be the user interface enhancements (settings that control what is seen on the LED display), that can be coded and tested from the comfort of my armchair using my production test jig, and now need to move onto the changes that need to be tested live on a real pachinko.

The test jig just loops back the signals that tell the pachinko to pay out balls, which is fine for testing that the dongle hardware is working correctly in a production environment (before doing the final tests on a real machine). But it doesn't allow you to test your changes still work correctly when you're messing around with stuff that could potentially alter the signal timings sent to the pachinko.

So seeing as I don't have any pachinkos within reach of my comfy chair, this next stage is not only going to need the mental effort required to write the code, there's also going to be physical effort involved (walking into the next room).

So to summarise...

There is a new 'Zero display' option, which allows you to select what you want on the LED display when there are no credits available. These are the original '0', a blank display, a blinking '0', an extra bright blinking '0' (for rubberratt), and the display animation shown in post #3 followed by a blank display. I managed to get all these changes (including the animation) into 120 bytes, so there should be no problems including them all in a code update for the older dongles.

I still need to add a little bit of extra code so that these options work with the '---' smartcard not present display.

Next job is to add the logic for multiple payouts (rather than the original always 25 balls payout). This means changes to the state machine logic that controls the payout sequence, which is quite a complicated bit of code where timing is critical. Seeing as I haven't modified it since the beta testing of the first prototype dongles, it's probably going to take quite a while for me to get my head around it and work out where the changes need to be made.

After this, I'll still need to add in the code for the self test and burn-in modes, but these are not so important as they are only for my own use and will be locked out once the production dongles are shipped out. So I'll probably add them some time during the beta testing phase.

[rubberratt]

an extra bright blinking '0' (for rubberratt)
Yay !!! fetch the SOFT CUSHIONS for Daverob's comfort.

TY !!!

(MAXIMUM Virtuosity enabled)

[new in town]

Even with me having to re-design the PC Boards and Re-Write the Code for the Micro's to adapt Autoslot to the new Pachislo's, "It" does not Compare to the R & D effort that you have put Forth Sir.

[daverob]

"It" does not Compare to the R & D effort that you have put Forth Sir.

I must say that it was a lot easier when I was working on the original prototype dongles, as back then I'd been recently laid off and so had a generous settlement to live on and plenty of time (between looking for work!) to design the dongles. This time I've got a lot less spare time to fit it all in (which is why it's taking so long).

Not much progress to report, I'm doing a bit of a tidy up and bug fix on the code as it stands before I start on the multiple payout code.There's a few unexpected interactions between some of the new options and a few display glitches that need to be sorted out.

I've added a another 'Zero display' effect for when the credit runs out and the display shows '0'. This option displays the zero for two seconds, the display then fades out and remains blank until more credit is added.

I added it this one as when I was testing the blank display effect, it didn't seem quite right to me when it went straight from ' 1' to blank without showing ' 0' at all, and then once I'd modified it to show the zero for a couple of seconds, the transition from ' 0' to blank was a bit abrupt.

I quite like this fade out effect, if I get the time I might look and see if there are other occasions where a fade in or fade out would be appropriate.


I've also solved the comfy chair issue. I've assembled a second 'test jig' board with just the two buttons and display circuit, and connected it to a really long cable that connects the payout signalling connections to the pachinko machine. This way I can sit in my chair and use the buttons and display on the test jig to test the software modifications while it triggers the actual payouts on the pachinko machine in the next room.

The top hopper on the pachinko machine cabinet holds more than enough balls, and an elastic band round the ball drain lever means balls automatically drain from the shooter tray into a parlour style ball tray, so I don't have to get out of my chair until this ball tray fills up. This means I can now be nice and comfortable (and lazy!) for nearly 100 payout cycles.

[Moparformances]

appropriate.


I've also solved the comfy chair issue. I've assembled a second 'test jig' board with just the two buttons and display circuit, and connected it to a really long cable that connects the payout signalling connections to the pachinko machine. This way I can sit in my chair and use the buttons and display on the test jig to test the software modifications while it triggers the actual payouts on the pachinko machine in the next room.

The top hopper on the pachinko machine cabinet holds more than enough balls, and an elastic band round the ball drain lever means balls automatically drain from the shooter tray into a parlour style ball tray, so I don't have to get out of my chair until this ball tray fills up. This means I can now be nice and comfortable (and lazy!) for nearly 100 payout cycles.

"Necessity is the mother of invention" Plato... But i dont think he ever said "Lazyness is the mother of invention"

[daverob]

"Necessity is the mother of invention" Plato... But i dont think he ever said "Lazyness is the mother of invention"

Well someone must have said it, as I reckon it would be appropriate for at least half of the tools in my workshop, and most of the inedible stuff in the kitchen.


Just added the code to blink the display digits during a payout cycle. I'm really liking this addition, I keep pressing the ball loan button just to see the effect. Need to stop pressing it now, or I'll have to get out of the chair to empty the ball tray before it overflows.

[rubberratt]

Super Kewl !!!

[daverob]

Ok, I think that's about it for the modifications and new features, everything on my list of 'things to do' now has a tick next to it, so it's time to begin testing (and the inevitable bug fixing!).

Made quite a few changes this morning to fix a whole load of glitches and interactions between settings (mostly to the 'freeplay' and 'emulation disabled' modes).

Added the last display setting that controls whether the display is blanked or shows '- - -' when there's no card present in the card reader slot.

Added the two settings to make multiple payouts. First one allows you to choose if you want 25 balls paid out for one credit or a multiple of 25 (ie 25,50,75,100...), the second setting allows more than one payout to be made for each ball loan button press, (ie one credit's worth of balls, two credits' worth of balls...)

I've also put place-holders in for the self test and burn in code, but haven't implemented them yet, as they won't really be needed until I go into production with the new design dongles.


I've now got a huge amount of testing to do on this 'Alpha' version of the software, I haven't written/updated the test specification yet (as with the first revision of the dongles, it will be done as I do the first run of testing). The number and complexity of some of the new options looks like it will at least treble the number of tests compared to the old dongles (which had 208 test cases to run).

Hopefully there won't be too many bugs to fix, as I really don't want to have to run through these tests too many times.


I guess this also means that it's getting close to Beta test time (and I still only have 4 dongles assembled!). Once I've decided what I want to get out of the Beta testing this time around, and worked out a proper selection criteria for testers, I'll post a request for volunteers in another thread, so keep a look out in the next day or two if you think you might be able to help out with this.


I've also done a quick build of this new code for the current production rev 1.1 dongles. I've only done a few rudimentary tests on the older hardware, but it looks OK so far. So once all the version 2 testing is complete I will update my current stock of dongles with this new software, and also offer a software upgrade option for the 100 or so of this version that have already been sold. I'm not totally sure about a software upgrade for the rev 1.0 dongles yet, as the microcontroller chip has a few differences, which might make things more difficult. But I'll have a go at back-porting the new software once everything else is done and out of the way.

[daverob]

Got through a fair amount of testing today, what was about 50 tests on the old dongles is now 180 tests on the new ones, due to all the extra options and features.

Found two more bugs that are now fixed, one where the setup mode display started flashing when one of the options was modified, but only if the setup mode was started using the jumper/buttons and not the new specially coded 'setup smartcard'. This was due to a new setting that had not been initialized when the setup mode was entered with the buttons, but the check for the smartcard was later in the power up sequence so didn't suffer from the problem.

The second was an interaction with the zero display option and the display blinking during payout option. When I added both of these options I had thought that there would never be a case where you'd have a payout with a zero on the display (as you'd have no credit so no payout), but I'd forgotten about the 'freeplay' modes where the display simply counts the number of payouts you've made (which start at zero).

Going to be a busy weekend for me (in my normal job), so I might not get much done over the next few days, but still confident that I should be ready for beta testing mid next week, so the call for testers has gone out on this thread, read it and reply if you want in on the action.

[rubberratt]

I can't wait to be able to push the button ONCE and get 100 balls

[KimbaWLion]

When I get a little spare cash a Dongle will be in order it seems :-) I have been following for awhile but been too busy trying to get machines, might be time to fine tune a few with a dongle. On my daughter's 17th Bday (on the 22nd btw) A dongle one each would have been VERY useful to control their ball flow so I was not running from machine to machine to keep the shooter ball tray full!

[akkashirei]

"(Some palours use a trayless system where balls are dropped into a bin under the lower tray and counted as they come out. The value is stored on your card.)"

This would be amazing! So that you could have the tray in a cabinet (behind plexiglass maybe so you can still see the balls dropping... or a metal fence/gate thing to hear it too) and keep your winnings on your card! Basically you would need a ball lifter and counter... But I think it would be worth it
It would have to show your value on your card going up as they dropped

EDIT: bit of a necro, my bad.

[compirate]

Here's a company that sells the system in Japan

[akkashirei]

Thanks, from the pictures that looks perfect!

But, I can't read Japanese, and google translator failed miserably.
Also I don't see where you go to buy it, or really anything considering I don't know what it says.
It looks perfect though from pictures!
Specifically the II and III systems

[daverob]

"(Some palours use a trayless system where balls are dropped into a bin under the lower tray and counted as they come out. The value is stored on your card.)"

This would be amazing!

I plan to design an upgrade for the card reader emulator dongles to allow this kind of use. It will be a small counter module that you can design into your cabinet so that balls can be drained out of the lower tray through the counter module and into your ball lifter (if you have one). The credit for the counted balls will then be added back to the ball loan display on the machine (or your smartcard if you have the smartcard reader option as well).

While the new version 2 dongles have been designed so that they should be capable of connecting straight to the counter module (but I can't be 100% sure of this, as I haven't designed the counter module yet!), I'll probably add an extra chip to the sensor circuit board in the counter module so that it can also be used with the older dongles.

I've got no timescales on this project though, as I've got quite a few projects that need to be finished first. Especially seeing as the counter module is going to need a fair bit of mechanical design work, and some significant investment in new tools / equipment (if I'm going to have any chance of making it work!), which will make it a project for when time and funds allow.