VIP Class
  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by DJRobX

  1. 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 12/17/16: * 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 * 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 the more recent VP 10.2 betas found here: 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.
  2. Do you have the latest FPLaunch installed? I think FPLaunch has its own log also.
  3. 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.
  4. 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 ...
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. 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!
  11. 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!
  12. Yep, the one in that zip of Lucky's palette files. The other colors (red & blue) are coming through. Its just the score that's in orange, which I"m pretty sure is coming from VPM default. I used to have a brighter color set for VPM default, before I flushed back to default values, and that showed through at least with the old DLL. TWD LE with Cleland audio works fine for me, with Lucky's Pin2dmd.pal. It has a white->yellow->brownish palette that looks pretty nice. Haven't seen any crashes, but do remember that the TWD table is very sensitive to memory fragmentation issues.
  13. Twilight zone is still showing an orange score with this DLL.
  14. As a sidenote, it's nice to see non-VPM tables being done with VPX instead of FP. That Ghostbusters table does look very sweet. I'd say emulation is probably possible but it will probably take a lot of time. I think the starting point will be when someone to gets a dump of the SD card in the machine. Unlike older SAM, the game code updates only update game code - but would be better to have the whole OS image. I think some folks have already started picking at the game code update format too. The CPU is a lot faster than SAM, so getting it to perform well could be another hurdle, especially for the newer games with LCD screens. We also don't know what, if any protections/encryptions Stern might have in place to hinder emulation.
  15. Yep, that's exactly right. The contributors of this community are super impressive. Best example was when I was working on the LE RGB lights. I had finally figured out how to get the data, but I had a lot of work ahead of me to move that data into something VP could use, and I badly needed a diagnostic table, I made a post about it one evening. By the time I woke up the next morning, GTXJoe had created a test table, and Toxie provided some skeleton code. Those things would have taken me weeks to sort out. I don't think I've ever had such excellent support, even in my professional development career where people are getting paid! Once I finally had a test build, Fren ran with it and made that freaking amazing ST:LE table. Incredible teamwork. Such support definitely helps motivate me to keep going.. And of course nothing makes me happier than seeing all the great tables that utilize the new features like TWD LE, Mustang LE, Metallica LE, Scared Stiff, and forthcoming tables like AC/DC LE. I've been enjoying VP for a long time and I'm glad I found a niche where I could give something of significant value back.
  16. I think the ROM test menu in setup doesn't look at registry entries, so AT91Jit is not getting disabled in that scenario.
  17. Speaking of orange, if using your Twilight Zone PAL file, what color is the full intensity score supposed to be? With Freezy's latest DLL I see a "default orange" score but other colors (blue and red) seem to be correct. I have VPM set with default colors and the colorize option turned on. I think I saw a video you posted - isn't the score supposed to be white? It sort of seems like it's mixing the default/VPM colors with what's in the .PAL file.
  18. I have PAL files in use lots of SAM roms and they all work fine with AT91Jit. As expected - if there's no patch, there's no difference to the emulation core. The output chain isn't relevant to JIT/non-JIT. The colors are funky, but I assume that's because the PALs are supposed to be used with a color patch of course.
  19. If the ROM isn't patched, you shouldn't need to disable AT91Jit. That problem is specific to the commpatch. I'll dig into that issue as soon as I have some color patches that match tables that I use. Every color patch that's out there seems to be for a Pro table that I use an LE version of.
  20. Thanks for the video. That kind of looks like what I saw on my cab (and removing that line in the script fixes). On mine it's super rare, but it manifests more as a phantom flip after you let go of the flipper button. The reason is that that line of script tells the flipper to release immediately when you let go of the button, but VPM may be "behind", and continues to send the "Flipper on" signal, so it may "blip" the flipper back on before VP catches up completely with VPM events.
  21. You might reach out to Macro and point him at Freezy's project.
  22. Looking at that video, some of the difference is that he's using the modulated solenoid feature. In this case it seems particularly noticeable in the snake and the coffin. Look at his Walking Dead or Mustang table script, you'll see UseVPMModSol=1 at the top, then instead of SolCallback there's SolModCallback for those flashers. This allows the ROM to control the intensity level of those lights, instead of just on/off.
  23. Rolled back to original what? Vp? Probably optimization or something with the build. The particular build I posted has debug symbols enabled and some other things so I could analyze things if a crash occurs. The fix itself is unlikely to have a big impact on performance (it plugs a bit of a leak actually, so it might improve).. Sounds like Toxie will update official vp with the fix.
  24. I noticed looking at the script for TWD and Mustang there is some code that appears to try to release the flipper solenoids "early" If Keycode = LeftFlipperKey then SolLFlipper false End If You might try commenting that out or just delete those three lines. It's there for the right flipper too so I'm not sure why the left would be different. You're looking for the ones on KeyUp. The ones on KeyDown are already commented out.
  25. So when it triggers, it continues to go up and down while holding in. How rapidly is it doing it? It continues to do that for the entire duration that you hold the button? Is your DOF solenoid or flipper sound firing while that goes on?