Code change to enable SAM LE driver board support

[DJRobX]

DOF in star trek is fine.   A new version of the table is coming out with improved DOF (and eliminated all the EM-style scripting hacks), but that completely changed the DOF profile.    So you just need to wait for the updated table. 

[jawdax]

then I will wait. thank you very much

[GtG]

1 hour ago, DJRobX said:

I did, however, notice that the launch ramp sometimes has trouble.     The game is pulsing the solenoid bit so fast, the read loop sometimes misses it.   Changed the collection strategy a little bit to ensure any attempts to set are always caught.  Here's a fix for that.

 

vpm102816b.zip

Yup the main thing I noticed going wrong was the Mist feed. There's also Sol31 (game-on solenoid), which is still not working. I assumed more was broken, but after a few games all the other solenoids seem fine. Thanks for all your work.

[DJRobX]

7 hours ago, GtG said:

Yup the main thing I noticed going wrong was the Mist feed. There's also Sol31 (game-on solenoid), which is still not working. I assumed more was broken, but after a few games all the other solenoids seem fine. Thanks for all your work.

Ah, the Game On solenoids are handled really oddly in the WPC code.   Had it nested incorrectly, and there was an off-by 1 issue ontop of it.  This should fix that.

vpm102916.zip

[DozerAUS]

Heya Rob, have been converting some tables over to the new solmodcallback code and tried the Addam's family tonight.  The difference with DOF is just night and day and I'm finding it hard to go back to configs without it after using it.   Noticed with tafg (TAF Gold) tonight that everything except for solenoid 3 (Ramp diverter) works great.  Sol 3 seems to stutter (on real solenoid) and close the diverter prematurely.    Tried a couple of routines to combat it but none were successful.  Have not tried the rev, above though but will in the morning.  Thought I'd throw it in here in case you were working on it today and could take a look.  Thanks in advance - Dozer.

[sliderpoint]

3 hours ago, DozerAUS said:

Heya Rob, have been converting some tables over to the new solmodcallback code and tried the Addam's family tonight.  The difference with DOF is just night and day and I'm finding it hard to go back to configs without it after using it.   Noticed with tafg (TAF Gold) tonight that everything except for solenoid 3 (Ramp diverter) works great.  Sol 3 seems to stutter (on real solenoid) and close the diverter prematurely.    Tried a couple of routines to combat it but none were successful.  Have not tried the rev, above though but will in the morning.  Thought I'd throw it in here in case you were working on it today and could take a look.  Thanks in advance - Dozer.

Hey Dozer, were you using my taf1.3.1, I have not tried it with the gold rom?  I would be curious what the changes are in the script relating to DOF? (I don't have cool toys to test...). I started converting just the flashers to the solmodcallback and it is completely different (very cool).   Does anyone know if this changes the way the 8 step GI works with that?  Seems like I could get a much smoother level change on the GI this way.

I'll finish my flasher changes and put a link here for that table in a bit.

-Mike

[DJRobX]

4 hours ago, DozerAUS said:

Heya Rob, have been converting some tables over to the new solmodcallback code and tried the Addam's family tonight.  The difference with DOF is just night and day and I'm finding it hard to go back to configs without it after using it.   Noticed with tafg (TAF Gold) tonight that everything except for solenoid 3 (Ramp diverter) works great.  Sol 3 seems to stutter (on real solenoid) and close the diverter prematurely.    Tried a couple of routines to combat it but none were successful.  Have not tried the rev, above though but will in the morning.  Thought I'd throw it in here in case you were working on it today and could take a look.  Thanks in advance - Dozer.

That's the sort of problem yesterday's update ought to solve.    That's exactly what the launch ramp solenoid (kind of like a diverter )  was doing in Dracula too.  

 

[DJRobX]

31 minutes ago, sliderpoint said:

Does anyone know if this changes the way the 8 step GI works with that?  

WPC 8 step GI should already be sent to DOF in a similar manner as the modulated solenoids, I think it's just not translated to a 0-255 value (0-7?).    I don't know if you're able to tell DOF to multiply by 8.    The new modulated solenoid stuff doesn't touch GI.  

 

[sliderpoint]

21 minutes ago, DJRobX said:

WPC 8 step GI should already be sent to DOF in a similar manner as the modulated solenoids, I think it's just not translated to a 0-255 value (0-7?).    I don't know if you're able to tell DOF to multiply by 8.    The new modulated solenoid stuff doesn't touch GI.  

 

Yeah,  I just looked at it again, It's 1-8.  It's fine, I think I can just simplify what I was doing with it.

-Mike

[sliderpoint]

OK, here is my TAF with the flasher changes. I didn't mess with GI.

-Mike

The Addams Family (Bally 1992) v1.4.zip

[DozerAUS]

5 hours ago, sliderpoint said:

Hey Dozer, were you using my taf1.3.1, I have not tried it with the gold rom?  I would be curious what the changes are in the script relating to DOF? (I don't have cool toys to test...). I started converting just the flashers to the solmodcallback and it is completely different (very cool).   Does anyone know if this changes the way the 8 step GI works with that?  Seems like I could get a much smoother level change on the GI this way.

I'll finish my flasher changes and put a link here for that table in a bit.

-Mike

Hey Mike, I think it is your version of the game - it's a PM5 conversion which I play with the gold ROM.

@DJRobX thankyou - the last update fixed the diverter.

So with DOF - once you add the necessary calls to the table script - Const UseVPMModSol = 1 etc. you can reconfigure the entry for the particular game like so.     Just say you have a RGB flasher assigned to pins 1,2.3 on your LedWiz and you current have an entry like "S32 White" assigned in your DOF config file.  This would generally turn RGB on to create white. Red on Pin1 - Green on Pin2 and Blue on Pin3.    The brightness of the white would bet set by the entries for what level the entry "white" has in the config file.   So without Rob's new modulated code, the ledwiz sees that the solenoid is on and turns it on or off with no gradient - it's either on or off and no in between.    By replacing the entry s32 White with three separate entries over the 3 pins and adding the "NoBool" flag like so S32 NoBool, S32 NoBool, S32 NoBool the ledwiz gets 3 modulated "0-255" levels on each of the pins 1 2 and 3.   So the color is still white but it is now illuminating with varying levels instead of just being on or off.     With TAF, the white flasher near the swamp now pulses and fades quickly instead of being on off and there are very subtle rates of modulation between the rest of the flashers so it is as the original programmers intended the flashers to work.  It's a small thing but every little bit of accuracy helps the immersion.   Hope this all made sense

[CarnyPriest]

21 hours ago, TerryRed said:

While this is working now for ddraw=0 with VPX in full screen, which is great....

I can't seem to get my DMD to be a perfect render like it was before.

What are you using for a multiple for your DMD resolution? (with ddraw=0)

 

I can't get a "clean" pixel perfect DMD anymore with this newer version no matter what "width or height" I use. My screen is 1366x768.

 

For my DMD with PinMAME, I tried:

 

1280x320...  I get uneven DMD pixels.

 

I tried 777x201, which before (with the older version) would make a perfect multiple of 128x32 (with the extra border pixels) and give 768x192. With the newer version this doesn't work correctly either.

 

 

Any ideas?

Following up on this post

http://www.vpforums.org/index.php?showtopic=34672&p=361457

There is a at least one SAM table that I am aware of that has a secondary playfield display. A candidate for a base setting to display pixel perfect output:

wpt_140a -> 257x101

Multiply the width and height by some integer and change the settings in the registry. Try it out.

Example, with my third monitor, my native resolution is 1600x900. So, for a standard 128x32 DMD the VPM base setting is 257x65. For the highest resolution pixel perfect display I multiply the base setting by 6. The width is 257 * 6 = 1542.. I replace the value of dmd_width in the registry with 1542. The height is 65 * 6 = 390. I replace the value of dmd_height in the registry with 390. 

I'd like to go edge-to-edge on my third monitor so that the DMD image is as large as possible. I'll have to create a custom resolution in my graphic card's control panel. For me, it might be 1552x873 if it works as it would preserve the screen's 16:9 aspect ratio.

Thanks again to DJRobX for freeing up the restrictions on scaling with ddraw=0.

[DJRobX]

I think this thread wins for most hijacked.   I like it.    I'll check WPT out probably tomorrow and see what I can do about these incorrectly sized DMDs. 

New update:  WPC modulated solenoid aux board support for Twilight Zone (probably works for ST:TNG also).  I'm also sharing my hacked test script from ninuzzu's VPX table.  He has 2 or 3 different flasher objects and I'm not really sure what's the appropriate way to set them, so I just set all their intensities the same way.  This is the same thing I did with Scared Stiff too.  I intentionally set them overly "hot" to ensure the effects visible.  

http://pastebin.com/FWL2aGpU

There's some problem with the gumball machine I will investigate further.  

vpm102916b.zip

[arngrim]

dozer i tried s** white nobool without separating the color and it works great

[DozerAUS]

5 hours ago, arngrim said:

dozer i tried s** white nobool without separating the color and it works great

Ah that's great news man - I only tried that on my addressable led strips and not the ledwiz.  This will save a bit of time, thanks for checking it out.

[gtxjoe]

Do 

9 hours ago, DJRobX said:

I think this thread wins for most hijacked.   I like it.    I'll check WPT out probably tomorrow and see what I can do about these incorrectly sized DMDs. 

New update:  WPC modulated solenoid aux board support for Twilight Zone (probably works for ST:TNG also).  I'm also sharing my hacked test script from ninuzzu's VPX table.  He has 2 or 3 different flasher objects and I'm not really sure what's the appropriate way to set them, so I just set all their intensities the same way.  This is the same thing I did with Scared Stiff too.  I intentionally set them overly "hot" to ensure the effects visible.  

http://pastebin.com/FWL2aGpU

There's some problem with the gumball machine I will investigate further.  

vpm102916b.zip

 

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,...

 

[CarnyPriest]

There will be a release that merges all of these forks soon, I think. In the meantime, you should be able to use the latest dmddevice.dll in lucky1's thread with djrobx's build and have just about everything that is current except for PinSound support.

[bent98]

I hope one that supports color roms

[lucky1]

41 minutes ago, bent98 said:

I hope one that supports color roms

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

[jesperpark]

I think this thread wins the award for many things... 

Most hijacked, most exciting innovations, most confusing,  most releases of pinmame,  most exciting (Yes I listed twice) 

Thanks to Everyone 

[bent98]

47 minutes ago, lucky1 said:

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

 

I am doing that right now but is that the official fix moving forward?

 

DJRob mention this to me:

The reason for that issue is that the patch actually re-writes the Stern software while it's running, which the JIT compiler is not expecting.   It will require some additional work.    Lucky1 and Freezy are working on a DLL that will make it possible for me to see the color DMD output.  Once I get that, I will work on that particular problem. 

[lucky1]

You asked for support and it is supported already. That is the official fix for existing ROMs using In-Frame colorization.

The ROM file DJRobx is referring to is something new, which has not been supported before,
since there was no serial support in SAM emulation.

[bent98]

ok thanks for clarifying!. Can you explain what that new feature DjRob is referring to?

[Rappelbox]

If I understand correctly it is smartdmd side channel colorization. The serial output of stern Sam machines is used to transfer color data to the smartdmd or pin2dmd device.
Normal inframe colorization uses the top left 8 pixels to store palette data, and therefor sometimes look a little strange
With sidechannel you can avoid these pixels.

Implementing would mean that vpinmame is capable of reading these modified roms and there stored color information and turn them into colordmd-like colorization.

Greetings,
Dom

[bent98]

oh wow. I cant wait