Code change to enable SAM LE driver board support

[coolball]

Hi, I can’t play “twd” with vp 2825 or vp2818  and vpm102916b.

Table starts but before I can see the rom in the DMD the table crashes.

I tested Metalica, Star Trek and TRon, all these tables runs fine.

 

something new with vpm102916b?

[DJRobX]

6 hours ago, lucky1 said:

It supports the current color roms by turning of at91jit for these romfiles in the registry.

Did you get that to work somehow?  I thought we were only getting partial palettes or did you guys find a solution that issue? 

[DJRobX]

1 hour ago, coolball said:

Hi, I can’t play “twd” with vp 2825 or vp2818  and vpm102916b.

Table starts but before I can see the rom in the DMD the table crashes.

I tested Metalica, Star Trek and TRon, all these tables runs fine.

something new with vpm102916b?

Strange.   Nothing change that affects SAM.  The previous build worked?    TWD is still playing OK for me.

[DJRobX]

7 hours ago, gtxjoe said:

I missed the boat... What do I need to combine this vpm102916.zip release with to get PIN2DMD working.  I know there was modular vpinmame.dll discussion,...

 

I see new modular PinDMD stuff since I merged Carny's latest.   Being that I don't have a way to test it, I don't know if it actually works or not.    Carny and Lucky are pretty quick about picking up my changes.   

[coolball]

Yes DJRobX, that is very strange. Tested the table with an older version of VP and older vpmame.

Everything the same. I delete my cfg downloaded the twd_156 ROM again, the same.

 

PLease take a look on my crash.txt, maybe you got an idea.

 

best regards

Andreas

crash.txt

[bent98]

Are you using a color rom?

[Drybonz]

Sometimes TWD has some kind of memory issues and you have to restart VPX altogether if you have been running other tables.  Not sure if that's the issue you are having but thought I would throw that out there as a possibility.  This isn't something new though, and I don't think it has anything to do with the table... it's just a large file.

[DJRobX]

Here's a new Vpinmame for testing.  

1) Includes Toxie's fantastic ddraw=0 scaler (with a bug fix).
2) Fix TZ gumball machine when modulated solenoids are turned on.   It actually uses a FAKE solenoid to pop out gumballs.!  Grr I hate this code. 
3) Fix DMD size (empty black bar) issue with WPT, TSPP, Ripleys, and probably others with mini-DMDs.   This one has annoyed me for years.  What's weird is there was a pre-existing tag for hidden DMD objects, but it only HID things when MAME_DEBUG was turned on (That HAD to be backwards!) and was only utilized by one capcom game. 

 

*Edit" B verson - fixed Monopoly & NBA 

vpm103016b.zip

[coolball]

It is Halloween, a strange day. TWD works as before.

Thanks for helping.

[DJRobX]

2 hours ago, coolball said:

It is Halloween, a strange day. TWD works as before.

Thanks for helping.

Paranormal activity for sure.    I touched absolutely nothing that should affect TWD.     I'm glad it's working again though.

 

[luvthatapex]

10 hours ago, DJRobX said:

Wow, I never thought I'd see the day that Ripleys, TSPP and Monopoly displays would get fixed. Thanks for that!!!!

Here's a new Vpinmame for testing.  

3) Fix DMD size (empty black bar) issue with WPT, TSPP, Ripleys, and probably others with mini-DMDs.   This one has annoyed me for years.  What's weird is there was a pre-existing tag for hidden DMD objects, but it only HID things when MAME_DEBUG was turned on (That HAD to be backwards!) and was only utilized by one capcom game. 

[DJRobX]

19 hours ago, Drybonz said:

Sometimes TWD has some kind of memory issues and you have to restart VPX altogether if you have been running other tables.  Not sure if that's the issue you are having but thought I would throw that out there as a possibility.  This isn't something new though, and I don't think it has anything to do with the table... it's just a large file.

Yeah, something bad happens when you exit a table, but don't quit VP.    VPM stays loaded in memory instead of exiting.   Then on a subsequent table run, all the global objects remember their old values, instead of being initialized fresh like you'd expect.    So unless things were coded very carefully, behavior may not be right on the second run.  Even the Microsoft's libraries seem to get confused, debug builds will crash with an "isatty" (file handle) exception for some reason.    This is one of those things that's really painful to debug.   It almost works well enough for most people not to notice, so I don't think anyone's dug in deep enough to fix it.

 

[Drybonz]

Yeah, I notice also when it's been a while without a restart of VPX/VPM that you lose the sound in VPM or you start to get weird sound behavior that wouldn't otherwise happen, so I just started re-starting VPX after every few tables.

VPX also has problems with the editor crashing after a while... I'm guessing for the same reasons.  Really painful if you have been working on a table and neglected to save for a bit.

[GtG]

Dracula still has some problems with the game-on solenoid, sol31 cuts out at random moments during multiball

[DJRobX]

I'm just passing GameOn back through the normal channel now (you just get 0 or 1, using old logic).   Can't think of anything that would cause it to "cut out" differently than in other modes.   What are you trying to do with it exactly? 

According to some really old VPinMame documentation, GameOn is not actually supported in FlipTronics games post-TAF.   It's connected to the same output that GI comes from.  Maybe the GI somehow interferes with this operation since the actual hardware doesn't use the GameOn solenoid?

Quote

New Features:

Added GameOn solenoid for WPC games (Sol 31). Only used in games that don't use Fliptronics flippers (before TAF), but it seems like many later games still activates the signal. Can be used to disable bumpers/slingshots in VPM

 

[GtG]

I'm using it to disconnect the flippers from the solcallbacks, and I also have it connected to vpmnudge.SolGameOn so it turns off the bumpers and slingshots when tilted. Haven't been able to reproduce with UseVPMModSol off

[DJRobX]

I haven't been able to reproduce this with modsol on.   I connected a light to that solenoid and stays on solid throughout play.   If you can share your table with me and tell me the quickest way to repro it would be very helpful.

 

[GtG]

Here's my test table

https://www.dropbox.com/s/th3x0zkgnkzc0et/Bram Stoker's Dracula (Williams 1993)1.0 FSMOD ADV.rar?dl=0

Arrow keys spam balls everywhere to start the various multiballs, The script plays a tone when sol31 turns off. I'm using vpm103016b, if that helps.

[DozerAUS]

I'm just dropping this in here for reference. I have noticed with DOF on Williams tables particularly that even when solmodcallback is not used in any of the solenoid calls but the const variable for the new routines is turned on that solenoid on/off latency has increased. For instance when slings and bumpers are hit the on/off time seems to be around 800ms instead of the default 100ms. Even when a DOF entry is specified with a max time like s32 120 which means pulse on/off with a 120ms duration it is either being ignored or fired again during this timeframe to buffer several 120ms on states which gives the effect of just staying on. One other thing I have noticed is that mech calls to magnets seem to not work when their inbuilt on/off syntax is used but do work with manual on/off calls. I have not been copying the core.vbs across with each new release which may be the issue (just remembered this). So wilk try that next.

Sent from my SM-G930F using Tapatalk

[DJRobX]

Core.vbs has not changed since it was originally modified.  I just include it so people know they need to update if they are grabbing it for the first time.    

I think in the most recent version I had increased the overall duration to 60ms to try and ensure that no small pulses get lost, I'll reset that back to 30ms.    It definitely shouldn't be 800ms!

Can you elaborate on what you mean by "mech calls to magnets"?   Remember, I am not a table author.

 

 

[DozerAUS]

Ok some more info - this solenoid chatter only seems to happen on certain solenoids that use a call like this

SolCallback(16) = "bsTrough.SolOut"

If I assign that solenoid to a real contactor in the cab like this S16 50  which means pulse once for 50 seconds no matter what the duration of S16 is before it hits its off state - then I can hear the relay driving the real solenoid chatter.

If I change the table script to to

SolCallback(16) = "Trough"

and then create a sub like

Sub Trough(enabled)
if enabled then
bsTrough.ExitSol_On
end if
end sub

Then I get no chatter and the solenoid pulses correctly.

The magnet class seems to be similar in that if I  specify a magnet class like

Set mag3= New cvpmMagnet
     With mag3
        .InitMagnet Magnet3, 8  
        .GrabCenter = False
        .solenoid=24
        .CreateEvents "mag3"
    End With

Then the magnet seems to work but very intermittently and without as much strength.  Like it's turning on and off very quickly.

If I remove the .solenoid line from the entry above and put a solcallback routine in for solenoid 24 and write an associated sub routine which turns the magnet on if enabled then it seems to work properly.   Turning Const UseVPMModSol = 1 back to 0 without changing any of the script resolves all of these issues.

I noticed this first last night on Fren's STLE - the magnet below this ship was not grabbing the ball during vengeance multiball until I rewrote the routine to manually turn the magnet on/off based on enabled state.

 

 

 

 

 

[DJRobX]

For SAM (STLE case), I can see why that won't work, and it's a relatively easy fix.   cvpmMagnet polls core_GetSol,, and SAM doesn't store the solenoid state in the old variables when modulation is turned on.    I can just have SAM copy the states there so it stays in sync.   At least that case is clear.

I'm still confused about the BSTrough.SolOut vs Trough(enabled)    When you say "solenoid chatter" are you referring to DOF output?    What you do with solcallbacks has nothing to do with DOF's observation of solenoid signals.  When ModSol is on, DOF sees the modulated values always.     If the trough was actually chattering I'd think you'd see more than one ball launched?

Because WPC solenoids are a minefield, I don't touch the code that controls the non-modulated values..   So core_GetSol should continue to do the same thing regardless of whether modulated solenoids are turned on or off.   So it shouldn't have any issue with cvpmMagnet.   In fact, core_GetSol is the same routine that gets called get the GameOn solenoid state (we know there's no need to modulate it).    So it's very interesting that you're seeing it behave differently.   Wonder if something is clobbering a variable somewhere.   Hmm....

 

 

 

 

[DozerAUS]

Ah nice that the magnet stuff on sam is solved.

You're right, my mistake sorry, I had Const UseVPMModSol = 0 when I was playing with different routines to try to solve the chatter - it is still there no matter whether I change the routine to something manual - apologies for the confusion. The magnet in TAF PM5 however does seem to work better with a manual routine.

 There is something weird happening with DOF though and I'm starting to think it may be another relay chattering in the chain and transferring the sound down to the relay that controls the solenoid that I have mapped to the trough.     So this is the exact chain of events that I can reproduce each time.

This case is the physical solenoid in the cabinet with Const UseVPMModSol = 1
On BSD - solenoid 16 is trough out.  If I have an entry in DOF for S16 with no time interval after it then the solenoid works fine but it stays on for around 1 second which is the time it looks to be pulsed by the ROM.   Everything works fine no chatter.   If I want to specify a time interval after S16 like S16 80 which means stay on for 80ms only then the solenoid still stays on for 1 second instead of 80ms and hear a relay chatter.

If I set Const UseVPMModSol = 0 then the time interval of 80's is honored and the solenoid snaps on and off over an 80ms interval. 

The question could be posed that why don't I just let it stay on for its intended time and that would be fine for the trough but I have noticed that all solenoids seem to disregard the manual time interval in DOF which is problematic for things like bumpers which seem to have increased their on / off time over the default if no time is specified or if a lower time is specified like 60 ms then you get this weird relay chatter and they still pulse on and off at an interval which seems to be controlled by the rom.   In some instances it is handy to be able to specify a time off interval after the solenoid assignment so you can prevent a solenoid from staying on too long or increase the snappiness of bumpers which in my case are physical solenoids which return to their rest position via a spring.  What I am noticing now is that on quick bumper hits, the solenoid is still on when the switch is triggered again so you get like 4 switch hits and one snap of the solenoid.  Reverting to Const UseVPMModSol = 0 results in super snappy action. 

 

 

 

 

 

 

[DJRobX]

No apologies necessary!   These details are super helpful in trying to track down these little issues.    

I suspect the DOF issues you're describing aren't so much a problem with the solenoids but rather DOF not being coded to handle the scenario of additional boolean events coming in that are the same as the previous state (because this was impossible before).    Even when we're not talking about lights,  the machine will first send a higher voltage spike to move the solenoid followed by a lower voltage (pulsing) to keep it held open.

So the machine is actually doing something that looks like this:

000011111111111111111111100000000100000000100000000010000000010000000000100000001000000001000000000000000000000

For this, the old behavior and in non-modulated mode, VPM will send two events ... On, then Off.
A modulated solenoid may send 45, 255, 20, 25, 20, 21, 20 .... then finally 0.       The calculation method is imperfect, so the level won't always be exactly the same while it's being held open. 

Core.vbs tracks this for booleans and keeps the solenoid ON and does not "fire" again until the value drops to 0.   It sounds like when DOF sees an update beyond your specified interval, it turns the solenoid back on again.     That's pretty logical, there was no need to check the prior state before. 

In non-modulated mode, VPM is still tracking these pulses, but performs the "smoothing" before it outputs, so DOF/VP never saw this "chatter" before.

[DozerAUS]

Interesting - so there are conditional states available in DOF that can be assigned to a solenoid such as S16>1 AND S16 < 5 etc.

Based on the info above I assigned S16=255 NoBool which I would have thought would have only fired the solenoid when the state reached 255 and ignored any of the smaller patter numbers but then it won't fire at all. 

Based on the DOF docu NoBool will prevent DOF from assigning any number which is not 0 to 255.  So I would have assumed that even though it sees positive numbers that are not 255 it should not fire.

I'll keep digging