Code change to enable SAM LE driver board support

[DJRobX]

Per request, I am updating the original post in the topic to include a set of builds related to my changes.   I don't think I had planned for the journey ahead when I started this thread.  

VPM 

http://vpuniverse.com/forums/forums/topic/2933-sambuild29-beta-thread/

* LE Aux Board Support
* WPC Modulated solenoids
* Miscellaneous sound and graphics fixes
* (12/17/16) Reduce GTS3 Vblank interrupts, to fix overly fast animations in Tee'd Off and possibly others. 
* Minor tweak to modulated solenoids (fix AFM monsters).  

B2S 11/26/16 (** Now included in official release and VP 10.2 installer **) 

http://www.vpforums.org/index.php?app=downloads&showfile=12553

* Fix intermittent string error when modulated solenoids are in use
* Add support for 128 bit LED segments (for World Poker Tour)
* Add some missing VPM interfaces
* Increase number of supported lights

DOF 12/06/16:

https://www.dropbox.com/s/qncfdegwj899fby/dof120616.zip?dl=0

* Contains a small fix to prevent over-firing when modulated solenoids are in use
* Fix to the fix - so combined effects like drop targets fire properly

 

Please use these in conunction with official vP 10.2 or later. :

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

An updated core.vbs script included in VP 10.2 is required for some of the newer tables to work correctly.   If you see errors related to "ModSol", then VP has picked up an old version of the core.vbs script.

 

---=== Original post from Sept 8 ===---

 

So it turns out, LE aux driver support is already present in sam.c.    There's just a hack that's preventing it from working properly. 

Near line 512 in SAM.C look for: 

                 case 6:
                sam_bank[4]++;
                if ( sam_bank[4] == 1 && bank >= 0)
 
Change the last line to:

                   if (core_gameData->hw.gameSpecific1 == 0 && bank >= 0)

And bam, you can see all 8 of the LE solenoids fire as Solenoid 33 through 40!   Tested using the X-Men LE rom. 

Not much concern of this code change breaking something else.  That block of code only updates the solenoids2 variable.    

The sam_bank[4] stuff appears to be some sort of hack that's also present on the other solenoid bank to prevent misfires.  It causes it to ignore the first attempt to set the solenoid.   But the way the ROM is updating the LE driver bank,  we miss the event if that hack is there.    

There are a couple conditional blocks of code below it for a SAM Mini-DMD.  I'm guessing this connects to the same port on the SAM board.  I added the check that hwgameSepcific1 is 0 to ensure that games with alternate hardware connected to that port doesn't trigger the solenoids. 

[gtxjoe]

Interesting find.  

Mustang has a bunch of additional light inserts on the aux board, lights 81 - 108, I wonder if this uses that mini dmd outputs

[bent98]

awesome find. next thing you will tell me is there is SPIKE support  hidden too.

[CarnyPriest]

I've got to concentrate...

concentrate... concentrate... I've got to concentrate... concentrate... concentrate...

Hello?... hello... hello... Echo... echo... echo...

Pinch hitting for Pedro Borbon... Manny Mota... Mota... Mota... 

[DJRobX]

GTXJoe:  Does Mustang use both extra solenoids and LEDs or just LEDs?   There are 3 different existing "game specific" implementations connected to this same output, one of which might work for the Mustang case

#define SAM_MINIDMD  0x01
#define SAM_NOMINI2  0x02
#define SAM_MINIDMD3 0x04

The last two options write to a LED matrix.

Those #defines are probably not well named as sam.c was decompiled from a binary (lots of funny variable names and such ) 

[CarnyPriest]

With the site upgrade I'm not sure how to update the VPinMAME page with a new version. Until we get that figured out, here's version 2.38 which includes DJRobX's LE aux board fix and brings the rest up to date to r3943 of the official build. This is just the NON_PINDMD_PINDMD2_PIN2DMD for now. Please post issues here.

VPinMAME_SAM_NON_PINDMD_PINDMD2_PIN2DMD_2.38.zip

[Ginsonic]

Link to attachment does not work 

[toxie]

JSYK: Some pinmame sound cores are currently a bit under reconstruction, so some cores may sound funny (that's why there was no official beta release in a while, until this all settles).

If this is the case, please compare the sound directly to the latest official VPM release 2.7, and if you hear a "negative" change, please let me know.

Changes so far/in progress:

Improve sound pitch for old Sterns (Catacomb, Flight 2000, Freefall, Lightning, Orbitor 1, and Split Second)
Further improved BSMT2000 sound core for Sega, Alvin G., Data East (Batman and newer), and Stern (up to Terminator 3) DMD generation games
Further improved AT91 sound core for the rest of the Stern DMDs (Elvis, LOTR, RBION, Sopranos, Nascar/Grand Prix/Dale Jr.)
 but still one should avoid high volume levels for these machines (~24 and above, for example on Nascar)
Slightly improved FM sound emulation cores (like AY8910, YMF262 and YM2151: so a lot of Gottlieb generations, old Ballys, pre-DCS games, etc)
Improved HC55516 CVSD sound core (Gorgar up to Twilight Zone, etc) and add some lowpass filtering (active only on older machines) to remove some of the audible noise

 

(also if you think that some cores now sound better than before let me know ;))

[CarnyPriest]

I haven't had any issues with downloads since the upgrade. Anybody else can't get that attachement?

VPinMAME_SAM_NON_PINDMD_PINDMD2_PIN2DMD_2.38.zip

[sliderpoint]

no go on the downlo:    The page you requested does not exist

-Mike

[CarnyPriest]

Dropbox

https://dl.dropboxusercontent.com/u/45430846/VPinMAME_SAM_NON_PINDMD_PINDMD2_PIN2DMD_2.38.zip

 

[sliderpoint]

Is that file for x64?

[Dazz]

1 hour ago, CarnyPriest said:

I haven't had any issues with downloads since the upgrade. Anybody else can't get that attachement?

VPinMAME_SAM_NON_PINDMD_PINDMD2_PIN2DMD_2.38.zip

Not sure what's going on with attachments. I'll look into that issue.

To update the file in the downloads section... go to bottom and you should see "File Actions" and should give you the option to "Upload a new version".

 

 

[gtxjoe]

Looks like Mustang LE has additional lights from lights 81 - 144 (The added lights are the light grid and the RGB inserts) and also additional 12 solenoids being used.

 

[CarnyPriest]

6 hours ago, Dazz said:

Not sure what's going on with attachments. I'll look into that issue.

To update the file in the downloads section... go to bottom and you should see "File Actions" and should give you the option to "Upload a new version".

 

 

I don't have that File Actions button.

 

By the way, this is the 32 bit build.

 

VPinMAME_SAM_NON_PINDMD_PINDMD2_PIN2DMD_2.38.zip

[DJRobX]

9 hours ago, gtxjoe said:

Looks like Mustang LE has additional lights from lights 81 - 144 (The added lights are the light grid and the RGB inserts) and also additional 12 solenoids being used.

 

I've determined the additional work required to support the 12 solenoids (it's related to the old sam_bank[4] check).   The data comes in two chunks so I have to add additional code to split them up.  With the current code 4 of the solenoids overlap.

I haven't yet figured out where the additional lighting is being output to.  The stern service manual is vague about it.    The wiring diagram suggests that the aux board is only for 12 solenoids in this case.   So what ARE the lights above 80 connected to?   Even the ROM stops listing the wire colors above 80.  LOL.  I'll keep hacking at it to see if I can figure it out.  

I saw a video of the Star Trek LE.  Looks like it's using the same "addressable" daisy-chained hardware as newer SPIKE systems, but it's a completely separate board from the 12 port AUX solenoid board.   I just need to find the data output, then can start deciphering the protocol from there. 

[bent98]

awesome work!

[arngrim]

wow, keep up the good work

[arngrim]

wow, keep up the good work [emoji20]

i mean

[DJRobX]

I think I'm getting closer with the LE LEDs.

The Atmel AT91 SAM (SAM is an Atmel name short for Smart ARM based Microcontrollers ... who knew?)  has a couple built in serial ports.   The Star Trek LE board is apparently hooked up via a simple transceiver board which is RS232.    In At91.C there's a UART handler which is currently not handled.     I can see it repeatedly receives a pointer to a block of data in our SAM memory that's changing regularly.     I had previously identified the same block as a possibility when comparing memory dumps when moving between LED outputs in the diagnostic menu.  

Unfortunately the format isn't plainly obvious, but if this block of memory is in fact, the additional LED traffic, then I can set a breakpoint inside the MAME debugger waiting for the ROM to write something there, and hopefully look at the assembler code to identify how it's building that data blob.    I know x86 assembly, ARM's a a bit different, but the MAME debugger is pretty good if not a bit slow.

Wish me luck.  LOL. 

[CarnyPriest]

Good luck!

[freneticamnesic]

I missed this... very interested... Glad to see an ongoing effort in this,

[bent98]

Who ya gonna call? SAM Buster!!

 

[DJRobX]

Since I'm reasonably certain the serial port is where the data is trying to go, the next step is to handle the serial port events correctly (or at least build it out enough to make the ROM think it's talking to real hardware).   Currently I see the initial blob of data in the buffer that the ROM is trying to write.    The problem is that the ROM is not getting the signal from the hardware that the transfer is complete and that it's OK to move onto the next block of data, so we aren't getting the full "stream" of data going.   

This is a non-trivial thing to implement.   It's using DMA transfers and doing notifications with IRQs.   Good news is that I started my development career writing low level serial port routines, so I'm pretty familiar with the mechanics required to make it work.  I also found the matching datasheet from ATMEL.   Just going to take some time and experimentation to get it flowing.      

[DJRobX]

Now we're cooking!

DATA OUTPUT: 85 41 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FF FF FF FF 0 0 0 0 0 7F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

That 7F is the LED.  If I move one lamp over to the right, the 7F moves one byte over.    So, one byte per lamp.   Pretty simple.

From attract mode with lots of them on at the same time:

DATA OUTPUT: 85 41 80 42 0 42 42 42 42 0 42 0 0 42 42 42 0 0 0 42 FF FF FF FF 0 0 42 42 0 42 0 42 0 0 0 0 0 0 0 85 0 85 0 0 0 85 0 85 85 0 85 0 85 0 85 85 0 85 0 0 0 85 0 85 0 0 0 0 

The only thing now is that it takes about 2 minutes for the data output to start.   It sends a few bytes over an over for a while, might be looking for some kind of ready signal from the board.   Then just gives up and starts the blast of data.   Once it's moving, it's fast - the numbers change immediately as I move around in the diagnostic menu.