Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
DJRobX

Code change to enable SAM LE driver board support

Recommended Posts

Just to make sure... if we use the VPM 102416 or higher, GI will be broken on any tables that don't update for the new GI controller?

Share this post


Link to post
Share on other sites
7 minutes ago, Drybonz said:

Just to make sure... if we use the VPM 102416 or higher, GI will be broken on any tables that don't update for the new GI controller?

If you add support for ROM controlled GI and then use an older VPM, the table won't break but the lights simply won't turn on.   Or more specifically, you won't get a gi update telling the lights to turn on.   That means you could code the table to turn them on initially (maybe in TableInit).   Then VPinMame will just turn the GI off and back on again, if it supports it. 

That way anyone with any VPM can play, but they have to update to get the full light show. :)

 

 

 

  • Upvote 1

Share this post


Link to post
Share on other sites

Oh ok... thanks for the response.  But, for people that are wondering, if they update to the 102416 VPM, say, for example, if they play the LOTR table, the GI will still be working (using the old code), even if the table is not updated to support the ROM controlled GI yet?

  • Upvote 1

Share this post


Link to post
Share on other sites
8 minutes ago, Drybonz said:

Oh ok... thanks for the response.  But, for people that are wondering, if they update to the 102416 VPM, say, for example, if they play the LOTR table, the GI will still be working (using the old code), even if the table is not updated to support the ROM controlled GI yet?

Yep, if a table is not coded to receive GI updates, nothing bad happens when VPM updates them.  They just get ignored and all is well.   The old "faked" GI code will continue to do what it does.    There's a super remote possibility that someone attempted to connect GI updates in vain and that their "dead" code attempt will be woken up by the new VPM, but there's probably a 1% chance of that happening.   We saw something like that with new solenoids in Star Trek Pro. :) 

  • Upvote 4

Share this post


Link to post
Share on other sites

Awesome... sounds great.  Sorry for all the base questions... but also wondering what we will see with the ROM controlled GI?  I'm assuming since it will be controlled as the game originally intended we will see the GI go off and on more, etc?

Share this post


Link to post
Share on other sites
1 minute ago, Drybonz said:

Awesome... sounds great.  Sorry for all the base questions... but also wondering what we will see with the ROM controlled GI?  I'm assuming since it will be controlled as the game originally intended we will see the GI go off and on more, etc?

They're very good questions. :)

The amount of change will depend on the game.   My Family Guy machine pretty much never changes the GI.    I never even thought about it until someone mentioned that GI support wasn't working, so I tried it and saw that my FG does in fact turn the lights off if I tilt it.    It also flickers them if you bump it ("DANGER").  

A lot of games turn it on and off when the ball drains.   That's pretty easy to fake though.   It gets more complex if the game turns it off during a bonus feature or something like that.   Those things are a big pain for table authors since there's not really a simple way to identify what game mode is actually going on from a table script perspective.   If you have the ROM controlled support you just connect it and your'e done.    

Same goes with the modulated flashers.   There is a ton of scripting in Scared Stiff to try and simulate what the ROM does on its own.   It only gets you so far.   Now that support is here it's way less work for the table authors to get more accurate light show. 

 

  • Upvote 3

Share this post


Link to post
Share on other sites

New Build based on the latest version of DJRobX commits with modular DMD drivers in the first post here

PIN2DMD driver looks for pin2dmd.pal file in a subdirectory of your pinMame installation directory called altcolor/GameName 
e.g. you have to copy your palette file for TZ_92 into PinMame/altcolor/tz_92/ named pin2dmd.pal

  • Upvote 3

Share this post


Link to post
Share on other sites

Here's an update that fixes an issue with misfiring on the AUX solenoids that Dozer found.    I found a better method than counting writes to reliably get the right target solenoid bank.   Instead I use that same port the GI is on and look at bits 5 and 6 (similar to how the Tron LE ramp light selection works).

 

 

 

vpm102516.zip

  • Upvote 4

Share this post


Link to post
Share on other sites

Some really fantastic news!   Herweh has released the B2S sources.    This allows us to fix some issues that were very painful to work around.

Please test the following B2S build.   It fixes:

1) Increases the lights to 400 from 251 to support games like Star Trek LE
2) Converts modulated solenoids to booleans internally so using the WPC/SAM modulated mode doesn't negatively impact or crash B2S.  Full range should still be passed to DOF.  
3) Passes GetRawDMD commands through to VPM, so dual controllers are not necessary for things like Cirqus Voltaire, or hopefully ... eventually native VPX DMD rendering.

https://www.dropbox.com/s/5o61qx0gahc8r24/b2s102516b.zip?dl=0

 

  • Upvote 8

Share this post


Link to post
Share on other sites
49 minutes ago, DJRobX said:

Some really fantastic news!   Herweh has released the B2S sources.    This allows us to fix some issues that were very painful to work around.

Please test the following B2S build.   It fixes:

1) Increases the lights to 400 from 251 to support games like Star Trek LE
2) Converts modulated solenoids to booleans internally so using the WPC/SAM modulated mode doesn't negatively impact or crash B2S.  Full range should still be passed to DOF.  
3) Passes GetRawDMD commands through to VPM, so dual controllers are not necessary for things like Cirqus Voltaire, or hopefully ... eventually native VPX DMD rendering.

https://www.dropbox.com/s/5o61qx0gahc8r24/b2s102516b.zip?dl=0

 

Wow, things are really advancing, isn't cooperation great!!

Do we just copy the DLL for existing installations, or copy all files and run the Servregister.exe again?

Thanks

Rich

  • Upvote 1

Share this post


Link to post
Share on other sites
On 10/24/2016 at 5:09 PM, DJRobX said:

Bugfix build: SAM solenoid 51 was getting skipped.

vpm102416b.zip

This works great thanks on VP10 but when I use this DLL my VP Physmod 5 of ACDC won`t load? Is it because this is the 64bit DLL & I need the 32Bit DLL?

Regards Steve 

Share this post


Link to post
Share on other sites
47 minutes ago, Rysr said:

Wow, things are really advancing, isn't cooperation great!!

Do we just copy the DLL for existing installations, or copy all files and run the Servregister.exe again?

Thanks

Rich

Just replace the DLL and EXE.  Re registering should not be necessary.  

38 minutes ago, stevegooner123 said:

This works great thanks on VP10 but when I use this DLL my VP Physmod 5 of ACDC won`t load? Is it because this is the 64bit DLL & I need the 32Bit DLL?

Regards Steve 

Interesting.  This is a 32 bit DLL so that shouldn't be an issue.   I'll check AC/DC on my cab later.  

Share this post


Link to post
Share on other sites

Hi, gang. Posting here adds more to the confusion, but I am having trouble today updating the SAM build in the downloads section. Or uploading any files for that matter. I've been working with djrobx to integrate all of the great changes that have been happening in the last few days so that we have one updated build. 

Version 2.41

is up to date with official VPM source to revision 4044

this includes the latest sound cores

DMD brightness maps for AlvinG, incorporates the universal devicedmd.dll - this means that one build now supports all real DMD solutions [lucky1]

modulated flashers for WPC and Whitestar, ROM controlled GI support for Whitestar [djrobx]

S.A.M.

AUX solenoids, modulated flashers, ROM controlled GI support [djrobx]

compiled/optimized with VS2015 update 3

Please continue to post on any issues.

https://dl.dropboxusercontent.com/u/45430846/VPinMAME_SAM_2.41.zip

 

[Edit - new fixes have been committed to address devicedmd.dll - will post an update later this evening]

  • Upvote 3

Share this post


Link to post
Share on other sites

Carnypriest,

Why are your Dll's around 1.6 k and DJRobx's versions are around 6k in size?

Do you use a different compiler?

Just wondering?

Rich

 

Share this post


Link to post
Share on other sites

Good question.  It's probably mainly because I have debug symbols turned on in release mode.   That way if I spot something I can attach and look into it.    Now, if you're wondering why I don't just use debug builds for my own testing, debug builds come with additional baggage (runtime checks, optimizations are turned off, and pinmame debugger gets attached), which makes them too slow to play.    Aside from build size bloat, having it built with debug symbols shouldn't otherwise affect much if anything.  

 

Share this post


Link to post
Share on other sites

Lol, I'm no developer. If you leave debug code in I just merge it in with everything else.

Simple answer: I pack the dll with upx, same as PinMAMEdev. I'm not sure there's a clear advantage for doing this though. If someone wants to test performance packed and unpacked then I can provide both.


Sent from my iPhone using Tapatalk

  • Upvote 1

Share this post


Link to post
Share on other sites

Should be no issue using UPX.   It's generally more efficient to keep file size smaller as processors can unpack much faster than something can be loaded from disk.  It doesn't affect runtime performance either way.   

 

Share this post


Link to post
Share on other sites
1 hour ago, DJRobX said:

Should be no issue using UPX.   It's generally more efficient to keep file size smaller as processors can unpack much faster than something can be loaded from disk.  It doesn't affect runtime performance either way.   

 

Ok, I'll keep packing it then. I'm interested in improving runtime performance, so I updated the compiler to the latest stable Visual Studio release. Microsoft touts that some built-in C/C++ optimizations made it into this release so I'd be interested if the difference was generally noticeable. 

Share this post


Link to post
Share on other sites

Don't expect wonders from that.

If you want to experiment with compilers you should try to get your hands on the Intel Compiler, that -could- maybe make a bit of a difference.

  • Upvote 1

Share this post


Link to post
Share on other sites
9 hours ago, stevegooner123 said:

This works great thanks on VP10 but when I use this DLL my VP Physmod 5 of ACDC won`t load? Is it because this is the 64bit DLL & I need the 32Bit DLL?

Regards Steve 

I checked out AC/DC.  I also use a PhysMod5 version and it runs no problem on my cab.     When you say it won't load, what happens?   Have you tried Carny's build?    Some people have stated they need a reboot.    I did a bunch of playtesting and Carny's build looks good to me.    ?

Share this post


Link to post
Share on other sites
1 hour ago, DJRobX said:

I checked out AC/DC.  I also use a PhysMod5 version and it runs no problem on my cab.     When you say it won't load, what happens?   Have you tried Carny's build?    Some people have stated they need a reboot.    I did a bunch of playtesting and Carny's build looks good to me.    ?

It works now with the New download Revision you posted on here,Thanks very Much DJRobX

  • Upvote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...