Jump to content

Code change to enable SAM LE driver board support


DJRobX

Recommended Posts

Thanks for all the excellent work being done here. 

Just a heads up ... the DOF config tool will need to have rom entries added when using the latest versions of VPinMAME (im for Ironman, xmn fo X-men, and avs for The Avengers). 

Although tough to follow at times ( most times), the results produced are very much appreciated.

Link to comment
Share on other sites

  • Replies 856
  • Created
  • Last Reply
  • Content Provider

i just adapted the roms

xmen = xmn

iron man = im

avengers = avs

right?

edit : but i just saw that djrobx test builds are still no old names, can you update the entries to have the new official names rob?

Link to comment
Share on other sites

Nice one.  This new emulation is excellent, especially the ability (when DJRobX) implements it to do these gradients with flashers.   It's a pain especially with the SAM stuff to get boolean outputs only for flashers as you notice so many different flashup/flashdown rates on real games.

I was curious if these RGB sweeps could be done with DOF so I went to my cab tonight and took a RGB ledwiz bank and instead of assigning a color across the 3 outputs like normal I tried 

Lamp(#),Lamp(#),Lamp(#) for RGB respectively - I found that if you use the NoBool flag like trn_174h,L106 NoBool, L105 NoBool, L104 NoBool  the Ledwiz will mimic the sweep correctly and display both the smooth fade and the correct color gradients - very cool!

This will work with flashers and mimic the correct fadespeed with DOF too once that correct solenoid emulation is implemented.

 

Link to comment
Share on other sites

  • Content Provider
9 minutes ago, DozerAUS said:

Nice one.  This new emulation is excellent, especially the ability (when DJRobX) implements it to do these gradients with flashers.   It's a pain especially with the SAM stuff to get boolean outputs only for flashers as you notice so many different flashup/flashdown rates on real games.

I was curious if these RGB sweeps could be done with DOF so I went to my cab tonight and took a RGB ledwiz bank and instead of assigning a color across the 3 outputs like normal I tried 

Lamp(#),Lamp(#),Lamp(#) for RGB respectively - I found that if you use the NoBool flag like trn_174h,L106 NoBool, L105 NoBool, L104 NoBool  the Ledwiz will mimic the sweep correctly and display both the smooth fade and the correct color gradients - very cool!

This will work with flashers and mimic the correct fadespeed with DOF too once that correct solenoid emulation is implemented.

 

there! arngrim, new undercab config for star trek?

Link to comment
Share on other sites

  • Content Provider

i understand a bit better already, everything is done on the dof ini?
nobool? it reacts on ON and OFF? what about intermediate values?
star trek is an exception since we need additional script to communicate to b2s.server..

Link to comment
Share on other sites

9 hours ago, freneticamnesic said:

Yea was just experimenting with that...nothing happened.

The other option is.........a ton of materials. I wonder what kind of performance impact changing materials would have on VPX....time to find out :)

BUT light looks so much better

Yeah that's exactly what I was trying to ask fuzzel.  If we could alter the material's color properly at runtime it would solve the problem.  Although it would be better if the primitive "emitted" light.   

Link to comment
Share on other sites

  • Content Provider

Yea that would be easier... The way I'm doing it just won't work, and I don't think lights are the solution for it. It doesn't need to be bright, I think the current properties on materials are perfectly fine, but being able to change the color of a material would sold a headache. It might help Dozer with CV, it would help me with Futurama when I get around to it, and I am sure many more authors would find a way to use it if that was available. 

Any other tables that have been hiding this kind of thing? I didn't have a clue the lights weren't scripted right on Tron..what other surprises await?!?

Link to comment
Share on other sites

9 hours ago, arngrim said:

i understand a bit better already, everything is done on the dof ini?
nobool? it reacts on ON and OFF? what about intermediate values?
star trek is an exception since we need additional script to communicate to b2s.server..

Heya, yes everything is done in the .ini - the NoBool flag allows the gradients.   It would look even better on a Pacled 64 with 255 levels instead of the ledwiz but it still looks great.  I'm not sure this will work with Star Trek though due to the limitations you mention as no lamp data seems to get to DOF via B2S without scripting it manually.

Link to comment
Share on other sites

  • Content Provider

jut tried it and it works great!

 

although the dof config is easy to write, the configtool is not ready to support such config, i need to adapt it a bit

because the nowadays the rgb effects look like 

S48 White

but this config takes in fact 3 outputs, something that DOF decompose at runtime

if a toy RGB toy does nothing, it will look like this in the ini 

0,0,0

so this is the first time we use a RGB effect that is really composed from 3 different lamp states, i would never thought to look at the dof documentation, thanks Dozer :) 

so if we don't use 2 controllers like in star trek it will not work, and also if we want to use something like for a toy that is doing more than a compose of 3 lamps, i don't know how this can work, scared stiff was mentioned

or we use a solenoid and mention the color in the ini file, or or compose the output of the toy based on 3 lamps, but i don't see how to mix S48 White and L106 NoBool, L105 NoBool, L104 NoBool

so you can try by yourself by replacing in your ini the rgb undercab or rgb undercab complex by L106 NoBool, L105 NoBool, L104 NoBool (in the ini, not in the configtool itself)

Link to comment
Share on other sites

3 hours ago, arngrim said:

jut tried it and it works great!

 

although the dof config is easy to write, the configtool is not ready to support such config, i need to adapt it a bit

because the nowadays the rgb effects look like 

S48 White

but this config takes in fact 3 outputs, something that DOF decompose at runtime

if a toy RGB toy does nothing, it will look like this in the ini 

0,0,0

so this is the first time we use a RGB effect that is really composed from 3 different lamp states, i would never thought to look at the dof documentation, thanks Dozer :) 

so if we don't use 2 controllers like in star trek it will not work, and also if we want to use something like for a toy that is doing more than a compose of 3 lamps, i don't know how this can work, scared stiff was mentioned

or we use a solenoid and mention the color in the ini file, or or compose the output of the toy based on 3 lamps, but i don't see how to mix S48 White and L106 NoBool, L105 NoBool, L104 NoBool

so you can try by yourself by replacing in your ini the rgb undercab or rgb undercab complex by L106 NoBool, L105 NoBool, L104 NoBool (in the ini, not in the configtool itself)

It's cool huh? :)   -  I am keen to try it with flashers once implemented.  I assume that if you had a white flasher that had different fade speeds you would just do something like rom_name, S13 NoBool, S13 NoBool, S13 NoBool to get varying degrees of white brightness as all 3 segments should fade in sync once the emulation is there.  DJRobX said that at the moment the solenoid outputs are smoothed out so we are only seeing a binary value but hopefully in the future they will work like these RGB arrays.

Link to comment
Share on other sites

  • Content Provider

looking forward to the future then :)

i made an update in the configtool, if you replace and put @rgbsplit@ L106|L105|L104 in the RGB Undercab or RGB Undercab Complex toy config of Tron, the one that you use, it will compute as L106 nobool, L105 nobool, L104 nobool in the ini file, exactly what we need to have the effect like in my video, you must use the last VPM from DJRobX and DOF is already ready to receive that :)

I don't publish this update because if someone is using a combo with that toy, the ini will be messed up, don't mix this @rgbsplit@ with a regular RGB effect, it will brake the ini, just do like I explain above 

Link to comment
Share on other sites

12 hours ago, DozerAUS said:

It's cool huh? :)   -  I am keen to try it with flashers once implemented.  I assume that if you had a white flasher that had different fade speeds you would just do something like rom_name, S13 NoBool, S13 NoBool, S13 NoBool to get varying degrees of white brightness as all 3 segments should fade in sync once the emulation is there.  DJRobX said that at the moment the solenoid outputs are smoothed out so we are only seeing a binary value but hopefully in the future they will work like these RGB arrays.

I have this working for SAM flashers now.    It's going to require a core.vbs update so your VP script can receive the solenoid level instead of the boolean, but I confirmed the "slow fade sequence" when you complete Stewie Pinball on Family Guy is working.     This actually seems to support a larger number of steps (24 bit cycle), but it sends them much more slowly (slightly under 120hz).    I still have to figure out how I want to pass in the "Switch to modulated mode" setting to VPM, but I think there's some string array of settings that come in that might work. 

What I wasn't expecting is that I can also see the high intensity spike, then lower voltage signal go to the flippers.    So even that is being voltage-managed by pulsing from the ROM. 

I looked at a WPC game to see how similarly that works.   It looks like that case will be a little more challenging.   It seems to only write to the solenoid port when it wants to change something.    With SAM it's easy, it repeatedly writes the bit pattern over and over even if it's the same.  So I can just count them up as they come in.  With WPC I'm going to have to figure out some other "clock" to to determine where we are in the cycle when it writes. 

Keep up the good work on the TRON ramp guys!   Those videos are very exciting. :)

Link to comment
Share on other sites

34 minutes ago, DJRobX said:

I have this working for SAM flashers now.    It's going to require a core.vbs update so your VP script can receive the solenoid level instead of the boolean, but I confirmed the "slow fade sequence" when you complete Stewie Pinball on Family Guy is working.     This actually seems to support a larger number of steps (24 bit cycle), but it sends them much more slowly (slightly under 120hz).    I still have to figure out how I want to pass in the "Switch to modulated mode" setting to VPM, but I think there's some string array of settings that come in that might work. 

What I wasn't expecting is that I can also see the high intensity spike, then lower voltage signal go to the flippers.    So even that is being voltage-managed by pulsing from the ROM. 

I looked at a WPC game to see how similarly that works.   It looks like that case will be a little more challenging.   It seems to only write to the solenoid port when it wants to change something.    With SAM it's easy, it repeatedly writes the bit pattern over and over even if it's the same.  So I can just count them up as they come in.  With WPC I'm going to have to figure out some other "clock" to to determine where we are in the cycle when it writes. 

Keep up the good work on the TRON ramp guys!   Those videos are very exciting. :)

Great work :) - I think there are quite a few settings in most SAM roms for coil strength (at least for the slings).  Would be interesting if that PWM was available which could then be coupled with something like a sling shot object (Wall / Rubber or something) that applied an opposing force to the ball based on a gradient coming from the Rom.  Would be great to able to manipulate table physics of certain objects directly from the game settings like a real table.

Link to comment
Share on other sites

  • Content Provider

Good news DozerAUS!

Toxie added a command to VPX that lets us change the base color of a MATERIAL. If you find a material setting you like and want to change the color like this then it works. I think the settings I had in Tron were pretty good (opacity set to 4) and I'm happy with it. It at least means I don't have to use lights :)

http://www.vpforums.org/index.php?showtopic=35311&p=360045

I was going to toss together a quick update that icpjuggla can use to update his table when the new VPX build is released

Link to comment
Share on other sites

12 hours ago, DJRobX said:

 

2 hours ago, freneticamnesic said:

Good news DozerAUS!

Toxie added a command to VPX that lets us change the base color of a MATERIAL. If you find a material setting you like and want to change the color like this then it works. I think the settings I had in Tron were pretty good (opacity set to 4) and I'm happy with it. It at least means I don't have to use lights :)

http://www.vpforums.org/index.php?showtopic=35311&p=360045

I was going to toss together a quick update that icpjuggla can use to update his table when the new VPX build is released

That's a great addition and will work fine in desktop mode too - looking forward to seeing it.  I'll hold off doing any more to mine here with lights and wait for your update.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...