Author Topic: Scheduled drivers or other methods of offloading bit patterns  (Read 1149 times)

tomlogic

  • Wizard
  • *****
  • Posts: 113
    • View Profile
    • PinMAME for P-ROC/Linux
I've been doing some work in PinMAME to better emulate the shift register interface used for the saucer LEDs in Attack from Mars, and the helmet lamps in Bride of Pinbot.  For both of those machines, you have two signals, clock and data, used to shift bits into two shift registers so you can drive 16 outputs.

I've been able to shift bits out with a clock pulse every 15ms, but if I try to increase the frequency of commands sent over USB, it starts to drop bits.  This is using a pulseTime of 2ms in the machine configuration YAML and a series of function calls that eventually hit PRDriverStatePulse().

I'm wondering, without resorting to using the auxiliary bus controller (which is used by the alphanumeric display on BOP), if there's a way I could get a higher frequency of updates.  I had considered using the PRDriverStateSchedule() API, but that appears to schedule just 32 bits over the course of 1 second (31.25ms per bit).  I could use a patter for the clock output, but wouldn't have any way to synchronize changes to the data output.

And may I just point out that the API documentation related to scheduling could use some work.  Here's what I found in pyprocgame: "Schedules this driver to be enabled according to the given schedule bitmask."  And libpinproc: "Assigns a repeating schedule to the given driver."

No mention of the bit order from the mask (MSB first or LSB first), explanation of duration for each bit and how the cycleSeconds and "now" parameters affect it.

Gerry Stellenberg

  • Administrator
  • *****
  • Posts: 2399
    • View Profile
    • PinballControllers.com
Re: Scheduled drivers or other methods of offloading bit patterns
« Reply #1 on: June 23, 2015, 01:03:30 PM »
Using USB commands in an attempt to reliably drive logic isn't recommended, and using millisecond resolution on the helmet lamps or AFM saucer lamps wouldn't work.  I think the hacked linux kernel in WoZ allows for 1ms cycle times, and that's nowhere near fast enough to clock in dynamic patterns of data on the lamps.  I'm curious why you want to move away from the aux port.  That's what it's there for (driving external logic, and doing so at sub-microsecond resolutions).  When I implemented the basic alphanumeric and BOP helmet lamp code in pyprocgame a few years ago, I set it up so that they could work concurrently in a single aux port program.

- Gerry

tomlogic

  • Wizard
  • *****
  • Posts: 113
    • View Profile
    • PinMAME for P-ROC/Linux
Re: Scheduled drivers or other methods of offloading bit patterns
« Reply #2 on: June 23, 2015, 06:24:05 PM »
Gerry,

I've just been hesitant to dive into learning how to use the aux port.  I incorrectly thought I wouldn't be able to use it on an alphanumeric machine.  Where should I go for documentation on how the aux port works?  I'd like to understand its design before learning the C API to configure it.  Where can I view pyprocgame code you wrote for the BOP helmet lights?

I also want to make sure that whatever I implement won't break the alphanumeric interface -- I won't be able to easily test that, since my friend's BOP (that I use for testing) has the BOP 2.0 Dutch Pinball upgrade and uses an LCD instead.  My goal would be for my PinMAME build to work correctly with the alphanumeric display, or the emulated version running on a DMD or LCD.

-Tom

Gerry Stellenberg

  • Administrator
  • *****
  • Posts: 2399
    • View Profile
    • PinballControllers.com
Re: Scheduled drivers or other methods of offloading bit patterns
« Reply #3 on: June 25, 2015, 08:15:29 PM »
The aux port documentation is part of the FPGA specification, which I yanked from the site when I learned of competitors trying to clone the P-ROC.  I need to pull out the aux-port documentation and provide it as a separate document, which I'll do soon.  If you need it in the next couple of days, please email me.

- Gerry