PinMAME

[russdx]

has any one found a way of capturing the dmd images yet?

i would love to hook my real dmd display up to pinmame and play the games

[ecurtz]

If you want to dump the DMD graphics out to a file or something there are a few options. There is a function in core.c

Code:

void video_update_core_dmd(struct mame_bitmap *bitmap, const struct rectangle *cliprect, tDMDDot dotCol, const struct core_dispLayout *layout)

where dotCol is basically an 8 bit image of the DMD as it is shown on the monitor, based on the previous 3 frames.

This isn't very good for running our DMD, because what we really want is just the actuall 1 bit frame that is currently on the DMD. These are only available inside the architecture specific files such as wpc.c

Code:

static struct {
  UINT8 *DMDFrames[DMD_FRAMES];
  int    nextDMDFrame;
} dmdlocals;

Unfortunately this information isn't readily available to the COM interface.

There are a couple of ways to handle that if we decide to add the DMD information into the COM interface rather than just ditch COM and just build VPinMAME as a library. They are slightly boring and technical so I won't go into them unless somebody else is considering doing that code in the near term.


General status - I still haven't tried to actually run a game, since there are things in the test menus not working. GI still doesn't do anything at all, but that's low priority. There's also definite issues with the normally closed optos, and the clock is just plain broken (more than just the optos being inverted, it isn't seeing them at all) this is probably an indication of it fighting with the simulation and I bet the gumball machine wouldn't work either. There is specific code in VPinMAME for handling complex toys like those and I don't think I'm disabling it completely.

[gstellenberg]

General status - I still haven't tried to actually run a game, since there are things in the test menus not working. GI still doesn't do anything at all, but that's low priority. There's also definite issues with the normally closed optos, and the clock is just plain broken (more than just the optos being inverted, it isn't seeing them at all) this is probably an indication of it fighting with the simulation and I bet the gumball machine wouldn't work either. There is specific code in VPinMAME for handling complex toys like those and I don't think I'm disabling it completely.

I'm curious about the normally-closed issue.  Perhaps you need to grab the initial machine switch states at startup time, like we're doing in LoadSwitchStates() in pinproctest:switches.cpp?  I wonder if the original software is initialized with the proper switch states or if it scans the switch matrix at startup time to set up the states.

- Gerry

[ecurtz]

Good guess, but no luck. The only switches reported as closed at launch are an always closed (i.e. nonexistent) one and the geneva switch (odd, but maybe that gets set by the TZ specific code.)

[gstellenberg]

I'm confused.  Are you saying that when using something like LoadSwitchStates(), the P-ROC is reporting only those 2 switches as closed?  That would be peculiar.  Just about every opto switch should be detected as closed, unless the state of those switches is inverted by additional circuitry on the machine.

[ecurtz]

No, sorry - that's what I get if I start out reading the switch states from VPinMAME before I've set anything, in an attempt to identify the normally closed switches.

I think the switch events from P-Roc are fine at this point.

edit:
In retrospect it was obvious I wouldn't be able to get the switch states from the CPU, since those are all input only in hardware, I can only see any of that because of the emulation. I guess I was hoping the read routines might just be going straight to the memory block or something.

[gstellenberg]

Hmmm, ok.  Do you have a good way to run MAME with the TZ Visual Pinball table and monitor the communication that happens between the two regarding switch states at startup?

Perhaps you'll need to get the switch states from the real machine before you start up MAME?  That would more accurately mimic real life where MAME can scan the table's switch states at any time, even right at startup.

[ecurtz]

I'm already sending the full switch state from P-Roc to the VPinMAME between the time the game is set and the simulation is started, so it should be ok with the initial state.

I think it's pretty close now, and would probably work if I just hard coded certain things to match how VPinMAME thinks TZ works. I'm just being stubborn and trying to get it to work in the most generic manner and the fewest code changes. The easiest solution would be to add a few bits into the YAML file to define VPinMAME stuff and just require the YAML like the test program does. I'll probably end up doing that, but I'm going to mess with it a little more and try to get it going with only the information available from VPinMAME.

They actually just last week open sourced the Visual Pinball code, so I was hoping ot get some goodies from looking at that. But either they didn't include any of the COM code for talking to VPinMAME or I couldn't find it in my initial searches.

[ecurtz]

The combination of flipping the normally closed switches and sending a complete switch state before starting the simulation seems to have gone a long way toward fixing the clock. Unfortunately, it still seems to miss some switch changes. I'm not sure if it is from an issue with the extra switch column and PRoc, or just a timing issue from the simulation thread being independent. The clock also stutters quite a bit, which is almost certainly a timing issue.

If we're looking for a reliable solution I'm pretty sure putting everything into a single application is a better long term goal. That would also remove the necessity of adding the DMD stuff into the COM interface, and probably allow builds for Linux and OS X as well, since the graphics and COM code could be dropped.

In the meantime I'll look at the YAML for Judge Dredd and hack together a version for the rest of you guys to play with (or possibly do it right and read the YAML, but I'm fairly certain we'll need to change strategies). You'd need VPinMame 2.2 and the JD ROMs.

[gstellenberg]

I wonder if TZ drives the clock motor with a pulse-width modulated signal instead of just turning it on solidly.  If so, the translation of vpinmame drive requests into PRDriverPulse() commands might cause the stuttering.  If this is true, it would be better to use PRDriverPatter() instead of PRDriverPulse().  However, the FPGA doesn't currently support the patter command with an overall duration; so we couldn't issue a patter request for 40ms or so.  If the PWM is needed, and we'll need to verify that, then I'll have to add a duration parameter to the Patter request and change the FPGA to disable the driver after the patter expires.

The implication here is that we'll need to know the PWM parameters for the clock hand motor and set it up correctly when running TZ through vpinmame.  This would be another thing that forces us to use a machine-specific config file, like a YAML file.  I know for sure other games use PWM pulses to handle things like up-posts and diverters.  I thought I could get away without putting in a duration parameter since custom games could just disable the driver when they're done with it.  For MAME though, we don't have that much control.

Eli, are you able to log vpinmame drive requests to the screen or to a file?  It would be nice to see the timing of drive requests vpinmame makes to the clock motor.  We should be able to extract the signal pulse widths from the log (if you print them out along with the system time).  I'm sure somebody on RGP could put an o-scope on the motor's drive pulse if we have to get the data from elsewhere.

Similarly, can you log switch events from the P-ROC?  The P-ROC will return all enabled switch events; so it should be fairly easy to determine if the P-ROC is missing the events due to an issue with the extra matrix column or if they are just getting lost in the COM interface or in vpinmame.  I suppose it's possible that using a PRDriverPulse runs the motor too quickly through the opto points, but that would surprise me.  Once we verify the pulse durations for the motor and set up an appropriate patter request, we can see if the switches behave better.

Regarding building the P-ROC support directly into MAME... I agree, it sounds like that's going to be the best way to go, especially since the COM interface doesn't include DMD support.  If we really will be able to run it in OS X and Linux, then that's an incredibly compelling reason to go that route too.  The obvious downside is that people would have to recompile MAME, but I suppose we could consider building and distributing a pre-built binary at some point if the project goes more mainstream.

Interesting stuff!

- Gerry

[gstellenberg]

One other thing, Eli.  The stuttering could also be related to you loop iteration time and the duration of your PRDriverPulse commands.  Can you post that data?  For instance, if your loop time is 30 Hz and your PRDriverPulse command uses 40 ms, then there could be 20ms after 1 pulse expires before the next pulse is received.  Note - a duration controlled patter would resolve this possible issue as well.

- Gerry

[ecurtz]

Just a quick update.

My BootCamp partition (letting me run Windows on my Mac) completely died this afternoon, so I won't be doing any work on this until at least next week. If anybody is impatient and wants the files to play with, I'd be happy to send them to you.

[Steven]

Out of curiosity: there hasn't been a post about the PinMAME implementation for some time. Is it on pause (maybe because of the partition problem), or maybe too hard or not possible to create and therefore cancelled?

On one hand I don't want to be 'pushing', and other than posts with questions like 'how far is it, how's it going?' or 'Great that there's new progress' I can't make for lack of knowledge. On the other hand it might be good for you guys to know it's beeing noticed when no updates are being posted for some time)

[ecurtz]

The Windows thing stopped me for a couple weeks, and then I got sidetracked working on MAME cabinets with some friends for the last two weekends. Suddenly no updates for a month... 

Windows has been restored to my Mac and I should do some work on it again in the next week. As Gerry suggested I tested the clock under direct P-ROC control and it didn't seem to miss any of the switch edges so I suspect that was an issue related to the COM and things not being synchronized properly. I've looked at the code a bit more and am pretty sure just adding the P-ROC interface directly into the PinMAME code is a better solution.

It is definitely not cancelled, nor too difficult. I'm glad you're excited for it - hopefully there will be some new progress soon.

[ecurtz]

As you can see I'm getting a lot of ghosting, I'm not sure if that is because something is configured wrong (I don't quite get how the P-ROC dmd config works - what is the difference between sub frames and frame buffers, if I have 3 of each then do I actually have 9 bitmaps in P-ROC memory?) or if my simulation isn't fast enough to keep up with the P-ROC frame updates.

I haven't added the light and switch code back in, but that was sort of working before in the COM version. The biggest hurdle so far was actually getting &%^$*#$ing Visual Studio to link everything with my various libraries.