Code change to enable SAM LE driver board support

[DozerAUS]

OK some success! - should learn to read properly - the condition needs to be in brackets.

So (S16=255) 60 only fires the solenoid once for 60 seconds when the level reaches 255 (The same as no modulation)

However the catch is that as per your overview above - 255's order in the string comes in on average about 100ms or so after the solenoid fires so there is a latency before being activated.  If I drop the number down to say 50 i.e. (S16=50) 60 then the solenoid fires straight away but no longer honors the interval as it must be seeing multiple states that = 50.

If 255 only appears once in the string, is it possible to make it the first number which gets sent or alternatively any random number that always gets set first? - this can then be assigned to solenoid calls with a condition.

[arngrim]

interesting, so you have that behaviour in which kind of solenoid? so without solmodcallback?
if you ask for a duration of 60ms and it stays 1 sec than yes there are repetitive on and off for 1 sec
and if you don't specify a duration it lasts 60 ms per default

Sent from tapatalk

[DJRobX]

10 hours ago, DozerAUS said:

OK some success! - should learn to read properly - the condition needs to be in brackets.

So (S16=255) 60 only fires the solenoid once for 60 seconds when the level reaches 255 (The same as no modulation)

However the catch is that as per your overview above - 255's order in the string comes in on average about 100ms or so after the solenoid fires so there is a latency before being activated.  If I drop the number down to say 50 i.e. (S16=50) 60 then the solenoid fires straight away but no longer honors the interval as it must be seeing multiple states that = 50.

If 255 only appears once in the string, is it possible to make it the first number which gets sent or alternatively any random number that always gets set first? - this can then be assigned to solenoid calls with a condition.

The added latency should be at most 16ms.   For pop bumpers I'm wondering why you don't just use the binary switch hit instead of the solenoid?  That would also speed up your latency since the switch event comes first. 

There's a caveat to just looking for 255.   If the game fires the solenoid smack dab in between refresh intervals it may not ever reach 255:

000000011111111111111111000000010000010000010000
[ <----  200 ----> ][<---200---->][<----22----><----20---->]

Another workaround would be to fire an EM style event from VP (since core.vbs will have handled the state tracking for you).

 

[DozerAUS]

11 minutes ago, DJRobX said:

The added latency should be at most 16ms.   For pop bumpers I'm wondering why you don't just use the binary switch hit instead of the solenoid?  That would also speed up your latency since the switch event comes first. 

There's a caveat to just looking for 255.   If the game fires the solenoid smack dab in between refresh intervals it may not ever reach 255:

000000011111111111111111000000010000010000010000
[ <----  200 ----> ][<---200---->][<----22----><----20---->]

Another workaround would be to fire an EM style event from VP (since core.vbs will have handled the state tracking for you).

 

Using the switch hit for bumpers and slings would work but it would require changing the DOF config for around 600 tables with switch entries in preference to solenoids.  It would also not work work for ballstacks / diverters etc. that use solenoid calls.  The issue with those is that in some games a solenoid driven diverter for instance may stay on for a couple of minutes during gameplay rendering the physical solenoid unavailable to other events where as with a time interval, you can get the effect of the diverter switching on with a 100m on / off pulse to the solenoid at which point other events can then use it.

I see what you mean with the 255 value - in some testing tonight it didn't appear for quite a while during the rom test.
I saw 9-31-9-45-4-40-68 during one test each with a snapshot each time the solenoid turned on.   If a unique number  cannot prefix the string, I wonder whether DOF could be updated to include a flag that only acknowledges the first positive number in the string and ignores the rest until it sees a 0 state again.  That would work too I guess. 

[DJRobX]

1 hour ago, DozerAUS said:

I see what you mean with the 255 value - in some testing tonight it didn't appear for quite a while during the rom test.
I saw 9-31-9-45-4-40-68 during one test each with a snapshot each time the solenoid turned on.   If a unique number  cannot prefix the string, I wonder whether DOF could be updated to include a flag that only acknowledges the first positive number in the string and ignores the rest until it sees a 0 state again.  That would work too I guess. 

Yep it's probably a really easy change to do in DOF code.   What you describe is pretty much what core.vbs does.     I think Swisslizard is on hiatus though?    I could patch the released code and then we cross our fingers that SL acccepts it when he returns?   

I think I read somewhere that the DOF sources aren't in a stable state but that there's some revision you can go back to that has working code. 

 

[DozerAUS]

1 minute ago, DJRobX said:

Yep it's probably a really easy change to do in DOF code.   What you describe is pretty much what core.vbs does.     I think Swisslizard is on hiatus though?    I could patch the released code and then we cross our fingers that SL acccepts it when he returns?   

I think I read somewhere that the DOF sources aren't in a stable state but that there's some revision you can go back to that has working code. 

 

Rob, thanks so much for the offer, I would appreciate it if you could - I know I'm being very granular here and you're being very patient with me but with that DOF addition this new modulated functionality would be perfect for both flashers and mechanical solenoids.  

[DozerAUS]

Just a quick thought regarding this  - the flag I mentioned would need to be something that is specified in the table config files for DOF  - directoutputconfig.ini etc. as a discrete entity rather than globally - i.e maybe something like S32 si=1 where si stands for string integer or something similar and the 1 means the first value seen because it's only the mechanical solenoids you want to control with this. in the config entry  - the flashers look amazing with modulated output.

[DJRobX]

Shouldn't be necessary.  Flashers with modulated output use NoBool.   So there's already a distinction for that. 

[DJRobX]

New build with some updates

1) Fixed SAM non-modulated coreGetSol when in modulated mode (for cvpmMagnet and possibly other routines that might try to access solenoids a different way).  Good catch on this one Dozer. 

2) Re-written No Good Gofers wheel using existing VPM mech movement API instead of a crude one-step-per-pulse scheme.  Old tables should work (but with more accurate wheel values), but a new set of values is exposed for easier table integration.   The wheel can now spin in both directions and is ROM speed controlled.   Here is the script I'm using for BodyDump's table with improved behavior.

http://pastebin.com/GVpSDHvW

Knowledge I gained on this one will probably also help with the Wheel Of Fortune wheel. 

vpm110216.zip

[arngrim]

does that mean if we use usevpmmodsol to 1, if we use solcallback it will behave like usevpmmodsol = 0 ?

i'm a bit lost because i think DOF doesn't care if you use solcallback or solmodcallback, i can fire the knocker when there is no solcallback in the script

tell me how do we handle wirth your changes in the script or with dof

[DozerAUS]

3 hours ago, arngrim said:

does that mean if we use usevpmmodsol to 1, if we use solcallback it will behave like usevpmmodsol = 0 ?

i'm a bit lost because i think DOF doesn't care if you use solcallback or solmodcallback, i can fire the knocker when there is no solcallback in the script

tell me how do we handle wirth your changes in the script or with dof

Hey Arngrim, DJRob is the best person to answer this and please feel free to correct anything (DJRobX) but this is my understanding of things.

When Const UseVPMModSol = 1 is specified in the table script then VPM sends modulated data to VPX and to DOF 

When a solmodcallback call is used in the script then the modulated data is sent to the routine associated with the call.
When a old stye solcallback is used in the script then core.vbs keeps track of the modulated data and sends a boolean on/off state to the routine associated with the call to mimic old style ON/OFF behaviour in preference to sending modulated data.
 

When Const UseVPMModSol = 1  DOF doesn't care about whether solmodcallback or solcallback is used in the table script.  DOF receives modulated data all the time. Without any modifiers specified in the entry for a rom in directouputconfig.ini for a solenoid DOF is written to convert any number it sees that is not 0 and positive to 255 (ON) or 0 (OFF). - Boolean   However when a NoBool flag is assigned then DOF simply passes the associated level to the output device.  This is how proper RGB colorization can be accomplished across 3 outputs of an RBG device.  Pin 1 may see any number from 0 to 255 / pin 2 the same as well as pin 3.  Without NoBool each pin will only see 255 or 0 because as soon as DOF sees any number higher than 0 it sets the output to 255 (ON) until it sees a 0 at which stage it sets it to OFF.

So you can see for flashers it works very well. 

The issue I have been hassling Rob about is that not only do flashers now see varying states of input with Const UseVPMModSol = 1 but outputs assigned to solenoids also see it.  

So consider a situation where you have a solenoid (number 16) for example that you only want to be on for 200ms and then turn off even if the signal for solenoid 16 from the rom stays on for 10 seconds.  Generally you would do S16 200 which as you know means turn on when S16 fires and then turn off 200ms later.   With Const UseVPMModSol = 0 DOF sees an ON signal and then 10 seconds later sees an OFF signal.  Our solenoid turned on when it saw the first ON signal and turned OFF 200ms later even though DOF did not see the OFF command from VPM until 9.8 seconds later.

With Const UseVPMModSol = 1 when solenoid 16 turns on we now see data like this for the time the solenoid is on.

45, 255, 20, 25, 20, 21, 20 .... then finally 0  < from Rob's example.

This seems to result in DOF receiving multiple ON commands each with a default duration of 100ms which I think is the default time on/off if no time interval modifier is set in the direcoutputconfig.ini for the specific solenoid.   This means that setting a time interval afterwards is ignored (well it's actually not ignored but added each block of data it receives) so setting S16 60 will now no longer work. You in fact end up with  S16 420  (7 block of ON data x 60).

You can try it yourself - set Const UseVPMModSol = 1 in a table and find a solenoid you can map to DOF (make sure it's one that stays on for 5 or 10 seconds while activated and add an entry which specifies a 60ms on time and then activate it - you should see that 60ms modifier ignored.  If you set it really small you should hear the solenoid chatter as the time modifier turns it off and then the next block of data in the string turns it back on.

 

 

 

[DJRobX]

TLDR: A minor tweak to DOF code will help solenoid responsiveness when ModSol=1 is in use.

 

[arngrim]

thanks Dozer, so we are aligned

but i don't understand in Star Trek LE with solmod = 1, i tested the public DOF Config that has nobool with flashers, normal effect without nobool for the rest, and i don't have the issue, but i didn't test the latest vpm yet

[DJRobX]

This is more of a performance tweak than fixing something that's broken.   Don't worry about it.  It doesn't require any changes on your end.  

 

[DozerAUS]

1 hour ago, arngrim said:

thanks Dozer, so we are aligned

but i don't understand in Star Trek LE with solmod = 1, i tested the public DOF Config that has nobool with flashers, normal effect without nobool for the rest, and i don't have the issue, but i didn't test the latest vpm yet

Looks like Rob is conjuring up some magic but to answer your question I don't notice it any near as pronounced on SAM tables as Williams.   I assume it has something to do with the different modulated data that is being sent. I know many posts ago it was mentioned that the modulation for Williams was done differently.

 

 

[DJRobX]

SAM sends its modulated signals out in a very regimented, predictable way.   We clearly see that a pattern repeats over a 24 bit history, so we see a pretty stable signal when SAM holds a solenoid open.    If the signal is stable, DOF doesn't see a change, so it doesn't "re-fire".

WPC solenoid handling seems more "analog" in nature.   The code seems to kind of write to the solenoid ports whenever it wants to (and only when it needs to).   So we sample the current states at certain time intervals to figure out the average level (amount of time it was pulsed on vs. off) over a certain time period.   The downside is that it may fluctuate a bit.   Core.vbs knows when you want a boolean so knows not to re-fire as long as the signal stays "on".    DOF understands boolean but doesn't compare the translated boolean value against the previous setting, so it will re-fire as soon as the state changes, even if the translated boolean was the same as the previous state.

I made a very small change to DOF and sent it to Dozer for testing.   The challenge here is that I don't have a solenoid on my cab, so my testing abilities are limited.

 

[DJRobX]

VPM update:

1) Improve flipper latency
1.1) (All games) Throttle the CPU at more intervals in between frame updates.  This gives more windows for the ROM and the table to communicate a change to each other.
1.2) (SAM,WPC) Make flipper solenoid changes immediately available to core, instead of waiting for VBLANK.

2) Another NGG update.   I noticed watching videos that the wheel is pretty agile, it makes "sharp" movements when the pop bumpers are hit.   Adjusted the simulation to more closely reflect this.    Note that the table script should not change (and is the same as the one I posted earlier in the thread).

Please note that #1.1 will change the distribution of CPU activity a bit.  Previously it would emulate at full speed, then idle for a long time until the next vblank.    This is bad because VPM can't respond to a flipper request if it's idling.      I found this change actually made VPM operate better on my cab (no more scratchy sound with VP fps limiter is enabled). 

 

DOF update:

Dozer is currently testing a small fix.   I had included MJR's changes, but those caused performance issues on his cab.   I rolled MJR's change back (but left my little tweak) and all is apparently looking good so far.     It makes the boolean solenoids not re-fire, so if there's a lot of overlapping solenoid action it can be more responsive (as it was before modulated solenoids were enabled).   Just backup, then replace your DirectOutput DLL with this one.  It's based on the R3 beta. 

 

 

DOFR3b110616.zip

vpm110616b.zip

[ultimate11]

Hello, I've been loving this thread ever since I found it, and I was wondering if you could fix that bug regarding the bonus tally in BOP (Bride Of Pinbot)? In the bonus, the display is supposed to flicker slowly, but in PinMAME there is no flickering.

I believe the same effects in Rollergames aren't fixed as well, as the jackpot sequence is just flat.

[bent98]

The sopranos visible lock bug was another annoying one. Below JP explains

 

http://www.vpforums.org/index.php?showtopic=23718&page=4

[ultimate11]

More details in Rollergames:

• W-I-L-L-I-A-M-S should be flickering per letter lit up, but it's not with PinMAME.
• The bonus, as I said, along with BOP, is not flickering during the #X display and the bonus accumulation.
• The Jackpot sequence flickers in the real machine (I think) compared with PinMAME.

Hopefully this might help you figure out how to troubleshoot the issue..

[DJRobX]

The lack of intentional flickering is almost surely a smoothing problem (similar to the problem we had with not seeing the flasher variations).    Of course you bring up Rollergames, the ONE VP9 TABLE that I actually officially modded and contributed back to the community in my entire time of using VP because I like that game a lot!      I'll take a look.  I'm not 100% sure how good fixing that will look (nobody runs VPM vsync'd), and it could get complicated with B2Ses that also try and draw an improved segment display.   

 

24 minutes ago, bent98 said:

The sopranos visible lock bug was another annoying one. Below JP explains

http://www.vpforums.org/index.php?showtopic=23718&page=4

I haven't looked into it specifically yet, but you might want to try this again under the latest VPX and with the latest Core.vbs.   Toxie and I found some pretty nasty timer bugs this weekend that can very well cause that, and they've been present since VP9.     Of course, if no one has made a Sopranos VPX yet, we'd have to wait for that.

[DJRobX]

Yep, the BOP thing is a smoothing problem.    If I lower the smoothing interval I can totally see it trying to draw the "rolling" segment levels as seen in this video:

 Essentially we need to make the segments colored like DMD pixels (in fact it works exactly the same way).   The nice thing here is that the interval is already figured out, so it's less work to derive the intensity level.  The harder part is updating things around VPM (B2S for example) to display these gradients/"colored" segments 

.  

[arngrim]

that is strange, i tried solmod in ngg, the only flasher that is working with it is this one

SolModCallback(51)="SetLamp 177,"                                    'Upper Right Flasher 1

all the other are off...?

[toxie]

The new throttle tweak leads to some problems on some machines. For example SFII hangs on startup on both VP9 and VPX.

(otherwise great stuff, of course :))

[DJRobX]

8 hours ago, arngrim said:

that is strange, i tried solmod in ngg, the only flasher that is working with it is this one

SolModCallback(51)="SetLamp 177,"                                    'Upper Right Flasher 1

all the other are off...?

Solenoids over 51 are aux board.     It's actually strange that it works with that one.    I previously added Modsol support for TZ and ST:TNG's ext boards, but other machines may do different things.   NGG has the aux board on a different address (aux board 2 instead of 1).    I'll have to add something to allow me to map which board the extra flashers are on. 

I had been focused on making the wheel work right, it didn't even cross my mind to enable modsol support for it, LOL.