VIP Class
  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by DJRobX

  1. It should be committed now.
  2. Hi @CarnyPriest, please make a build. I fixed a small issue with the external DLL support that was preventing Metallica 1.7 LE color patch from passing palette commands properly.
  3. 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 * 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 **) * 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: * 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. : 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.
  4. If you want the light show you can turn off 4xaa for this table and you should be able to handle it. That's what I do for my 960. Fortunately this table doesn't have a lot of wire ramps, so the quality doesn't suffer too much from disabling 4xaa.
  5. My DOF patch is still current and recommended. Swisslizard is on hiatus still I think. The VPM build you can use Carnys latest. I recommend the most recent beta he posted. The B2S update is included with official VP 10.2 now. I updated the first post to reflect all of this.
  6. The specific JIT crash this fixes has to do with color ROMs that have the serial side channel enabled. In some cases the patch produces "self modifying code", so additional logic had to be added to recompile modified code. Spider man color was one that would definitely not run. Jus for clarity, this is NOT a fix for the "intermittent" crash that some of you are running into with unpatched roms when used with Freezy's DMDDevice.dll.
  7. Yeah I'm afraid I'm already at the extent of my testing, it does not reproduce on this machine. That machine hadn't been patched since 2014. It worked fine initially. Updated to the latest-everything, continued to work fine. Tried turning on windows defender and a bunch of other stuff. PinballX, B2S, DOF, color DMDDevice.dll .... no ill effect, all runs fine. Tried rebooting several times, even loading multiple tables back to back without closing VP. Raw CPU won't help if you run into timing problems. What I mean is that bringing the non-JIT code up to functional parity with the JIT code will potentially slow it down a lot more.
  8. I remembered that I do have one other WIn7 x64 machine hooked up to a TV with 8GB and a Radeon graphics chip that does load VP. Unfortunately no luck so far reproducing the crash issue. I hate it when I can't reproduce issues other people have.
  9. I fixed that a couple weeks ago, but I guess it would help if I alerted @CarnyPriest to make a build. That was easy peasy. Just a matter of the game specific hack looking for "mt_145h" and the "mt_145hc" name not matching. I changed it to be 'anything that starts with mt_145h" and now it works fine with the color ROM. Mustang Pro and LE are the only ROMs that really require the game specific hack. TWD uses a "default hack" of blasting garbage data ta the serial port. Star Trek LE, Metallica LE, and AC/DC do not appear to look for any response from the serial port, so they don't need hacks. I hope some day, someone gets bored and determines what the real response the game wants from the serial LED boards is.
  10. JIT stands for "Just in time" compiling. It translates the ARM processor code into native x86 code and runs it directly. The non-JIT code, in contrast, is a standard C program that looks at each instruction and simulates its behavior. JIT specifically refers to the way the translation happens - it translates things on the fly as needed - "just in time" for use. JIT is significantly faster. I think MJR added this to VPM to better support the sound board in WhiteStar II games, which was later promoted to be the primary CPU in SAM. When I started working on the LE lighting for SAM, I discovered that I needed to emulate a serial port. Serial ports rely on something called an IRQ - Interrupt ReQuest - a hardware signal that tells the processor "Stop what you're doing!" - that some event (such as: "data has arrived and is waiting!") has occurred and needs to be handled. The IRQ support in the existing SAM and ARM processor emulation was very basic - up until the serial port, it was basically only being used for timers, and those are very predictable. To make the serial port work correctly, it required more frequent checking on each executed instruction that could possibly trigger an event. This meant that SAM emulation was going to slow way down unless I found a solution to make it go faster. So I spent a good solid month trying to track down various bugs in this existing JIT compiler that were preventing SAM games from running properly. JIT gave me more overhead to check for IRQ events on essentially every possible case that might trigger one. So, the non-JIT code works, but may not work as well. You might find stuff like slow DMD frames or the light strings "dying". Those are timing sensitive problems that took a long time to iron out completely on the JIT side. Fixing them might come at the expense of an even bigger performance hit. TL:DR = If you want all this to work right, I strongly recommend you install Windows 10. This is seriously complicated stuff, so a fix is probably not coming soon. At least not from me, since I don't currently have an environment to repro it.
  11. I suspect the problem is that the JMP calls made by JIT are not 4GB safe, but VP has that option enabled. Loading a .NET assembly in the middle of VPM might tip things over to where this is an issue. Windows 10 might use a different memory allocation strategy that makes this not a problem. Everyone with issues seems to be on Win7. Unfortunately VP doesn't run on our remaining Win7 machine (Intel graphics), so I won't be able to debug this. For now your options are to upgrade to Win10 or disable JIT.
  12. So I found out what was going on with the "No DMD device driver found" error I was seeing. I found that I am not able to load DMDDevice.dll if the table script loads VPinMame.Controller directly, it would only work through B2S.Server. The LoadLibraryEx call in VPM currently limits the DLL search to only the specified folder. So it would find the DMDDevice.dll, but then it couldn't locate a DLL it depended on (mscoree.dll). If loading through B2S, it - also being a .NET dll - loads this DLL first, so it bypasses the issue. Changing the LoadLibraryEx line to: hModule = LoadLibraryEx(filename,NULL,LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS); appears to take care of it and allows me to load VPM directly with the external DMD working. I committed the fix to Carny's repo.
  13. Need more details. Plunger has nothing to do with VPM. . When you say the plunger doesn't work what do you mean exactly? Is the ball in the shooter lane but you can't launch it? Do you have a mechanical plunger? If so what type? If NOT you may have a game controller plugged in that VP thinks is a plunger.
  14. @freezy If you add: this.ShowActivated = false; to the VirtualDMD() constructor in VirtualDMD.xaml.cs, it stops the focus problems
  15. Note that HyperPin+FPlaunch doesn't currently support VPX. You have to rename VPX's to VPTs. There's a file called VPExeTables.txt that you can use to tell FPLaunch which version of VP to use for a VPX file. If you're new to virtual pinball you might consider PinballX instead. It's newer, more supported, and easier to set up.
  16. Do you have the latest FPLaunch installed? I think FPLaunch has its own log also.
  17. Some people have reported minor performance issues with that build. It works fine for me though. If it's working for you, do feel free to keep using it as it appears to fix the crashing bug. It's otherwise based on the latest code. Once VPX dev gets around to starting the 1..3 cycle you can switch to theirs as it will also have a similar fix in place.
  18. I'm really glad you reported the crashing problem. It was just obscure enough that I would have assumed my cab was unstable or something like that. And having to play Metallica LE so much trying to reproduce it really sucked. I'll have to keep testing this update to make sure there are no other bugs ...
  19. That super-slow frames slowdown with non-JIT LE tables is an IRQ timing problem. Once that happens the LE lights/GI will stop also. TWD LE is the most sensitive to it. It's because the non-JIT code doesn't check for IRQ events as frequently and the serial interface freezes. That's the reason I spent so much time debugging MJR's the JIT implementation to make it work for SAM - checking to see if an IRQ triggered after every memory write slows things way down. JIT was the only way to keep acceptable performance while emulating the serial port.
  20. If I load Avatar (avr_110) from VPX, I get "No DMD device driver found". Doesn't matter if there's a PAL file or not. It's the only table that does this, I can switch to a different table and it loads fine. No log is generated. Same happens on two machines. Weird... *Edit* has something to do with the way the VPM controller is loaded. If I force ccontroller to 3 (B2S) instead of trying to use ccontroller.txt, it loads OK. Still weird, but now I know how to work around that. Does anyone else have focus problems? I never really noticed this because I was mostly using VPX tables in true fullscreen, but VP9 tables load and the virtual DMD is stealing focus. I have to alt-tab to the table to play them.
  21. 8GB Should be plenty. I just tried FGY color. Works fine with JIT on on both my cab and my laptop. JIT does use more memory than non-JIT, but if you have over 4GB it shouldn't be an issue. If you guys are using anti-virus make sure that your Visual PInball folder is excluded. Also if you can grab the crash.txt (it'll be in your tables folder) and share the contents of that it may be helpful.
  22. I'll try FG, I haven't gotten to that one yet. I'm not sure what's going on with your TWD, my Cleland LE ROM works fine with JIT + pal file. Which modified ROM are you using? Jesper - How much RAM does your pinball machine have?
  23. Don't have a way to test anything other than your virtual DMD driver, but I would think it almost has to be on the VPM side. I am looking into it.
  24. A-ha! You're right. My cab had a VPM from around the same time as the official VPM release. I ran it with a fresh build and now the palette is correct. So now just have the segmented display issue mentioned in the previous post. Thanks!
  25. It's strictly a memory thing, as long as you have more than 4gb of memory you really shouldn't be running into crashes post reboot. Share the crash.txt file and maybe that will give me more of a hint as to what's going on. I noticed something else weird about Freezy's virtual DMDDevice. More recent updates have segmented displays showing dotted output now, however, these result in strange MAME behavior. I noticed it on Taxi first, the Taxi ROM sometimes screeches and beeps particularly if you delete the NVRam file. The game sometimes starts and works OK though, if you get past that. Then I tried some early 80's pins like Mata Hari... The ROM would seem to crash and restart over and over, the game wasn't playable. Just switching from ShowPinDMD=0 and ShowWinDMD=1 makes everything go back to normal. It only seems to be a problem for games with segmented output, all the dot matrix games seem to work beautifully. So it seems like something really bad is happening for segmented output. I can't imagine what would have THAT effect though!