Guitar

Is there a comprehensive list of supported / non supported games in MFME anywhere?

At this point it's probably far quicker to list the ones that don't run.

Specifically I was wondering about "What a carry on" and "Cash Raid" on what I believe is spACE tech.

And "Around the world in 80 days" AWP on JPM System 5.

Hi all,

I was contacted on facebook to say that Player was trying to get hold of me on the mecca to get his Big50 back.

I have an issue though in that I cant log in to the mecca to contact him, can someone at least let him know I have replied, and possibly contact Pete W to ask him to check why my account is 'suspended'. I dont remember doing anything heinous, though its been a year or two so I could just have a selective memory.

I've been trying to get hold a large scanner to be able to get glass scans in a single image. But have found that the large scanners start around £5k and go upwards in price.

I have been in touch with a local scanning company and asked them if they are able to deal with the large sizes.

If they come back as unable to is there anyone on here who knows of a scanning company or person that would be able to do the job?

My intention is (if possible) to get all the glasses from my 7 JPM's scanned, to be able to create UHD/4k layouts.

I am also making arrangements to get a Vogue cabinet 3D scanned for use in Amber eventually.

Also, does anyone have a spare Indiana Jones top glass (with grail decals) as mine is a bit flakey in places?

Perhaps the element most important to the fruit machine, the diminutive light bulb.

One of the more simple electronic components too, apply a voltage to the contacts of the bulb, the filament heats up and as a by product it radiates heat and light, Easy.

But when it comes to emulation, because of their analogue nature, one of the more difficult properties to display in a realistic manner.

When I first joined the FME scene back when I was 14 [Insert strumming harp sounds] over at the now defunct mpuworld I tried to play a game called Place Your Bets, by Barcrest. I was informed by the regulars, some of whom may still be amongst us, that it wasn't playable because it used dimmed lamping on the nudges stack, so you never knew how many nudges you had as every nudge lamp would be lit. Those of you who have played this machine will know the importance of the nudge stack.

At the time I vaguely remember someone [probably Wizard or Dialtone] posting a more technical explanation as to what was going on and to be honest it flew so far above my head that my hair didn't even ruffle, yes, I had hair back then too.

I always thought at the time that it should be solvable, and all these years later I think I might be close to the solution, but it is far more complex a problem than I thought it would be. So join me as I take a look and try to, ahem, shed some light on the situation. [Pause for laughter][what, no laughter][fine]

Part 1 looks at how the lamps are driven, and some of the solutions offered so far.

There are 2 ways lamps are driven [powered] by fruit machines. The rarest is a direct drive where a lamp is connected to a single output, these are mainly found in older electromechanical machines, though Barcrest and BWB did do something similar by attaching a string of 8 lamps in series to a triac connection, usually for general illumination such as machine logos or belly panels. Club Connect, Blues Boys, & Road Hog do this to name a few. These are simple, and the state of the lamp (on or off) can be directly assumed from whatever emulated out is driving it.

The second way, which is by far the most common, is to use a multiplexed grid of lamps. In my example I will mostly be referring to JPM's IMPACT tech, but multiplexers work the same way on whatever tech they are on, they just vary in size and refresh rate.

IMPACT has 16 strobe lines, and 16 data lines, giving a total of (16 * 16) 256 lamps that can be used.

From a programming standpoint, they are very easy to use...

Set the strobe to 0, set the data lines to turn on or off lamps 0 to 15;

Set the strobe to 1, set the data lines to turn on or off lamps 16 to 31;

Set the strobe to 2, set the data lines to turn on or off lamps 32 to 47;

Set the strobe to 3, set the data lines to turn on or off lamps 48 to 63;

and so on until strobe = 15, and you have set the data for all lamps.

You then repeat the process over and over very quickly (known as the refresh rate).

The idea is that the process is repeated so fast that when the bulbs are on the power comes back round to them before they have a chance to completely cool down and still look lit up even though they aren't powered.

IMPACT's Roller Coaster has a refresh rate of ~66.6Hz. It's entirely likely that all IMPACT games use the same base operating system, and therefore all have a refresh rate of 66.6Hz but as the multiplexer is driven entirely by software it could theoretically be changed from game to game, though this is unlikely as there is no real need and programmers don't make more work for themselves if they don't have to.

Obviously you can't have something happening .6 of the time, if you measured how many times the multiplexer is driven in any one second, it would either be 66 or 67 times, but on average over many seconds, it works out to approximately 66.6.

The bulbs used in most machines are 10mm ,Wedge, 12 Volt, 1.2 Watt types. Newer machines tend to use the 5mm variant but the output light remains almost identical.

I'm not going to get too heavilly into the maths side of it today, just a general overview of what the problem is, I can get in to specifics later, and there's a lot of them when we get there.

If there are 16 strobes, and the time they are on is evenly split, then each bulb will only be powered for a maximum of 1/16th of the time. It is actually a little bit less than that but for basic purposes 1/16 of the time is a good figure.

So if we fed 12 Volts to the bulbs and then multiplex them, they would be very dim as they are not on for much of time, so they are actually driven by 50v AC, which is present in the machine for driving the payouts.

First of all, 12v is the rated DC voltage, and the supply is AC. Because AC voltage is actually a sine wave rather than a constant voltage, we have to use a formula to find what the (Root Means Squared) RMS or equivalent DC voltage is.

RMS Voltage = (Input AC Voltage / Square Root of 2)

So RMS Voltage = (50 / 1.4142) = 35.36 Volts.

Then we need to calculate to RMS voltage going to the bulb after the multiplexer.

There is another formula for this

RMS Voltage = (Input Voltage * Square root of (Frequency * Duration))

The frequency is the same as the refresh rate 66.6, and the duration is the time was actually powered up during the cycle.

These vary with measurement but a typical example would be..

RMS Voltage = (35.36 * Square Root of (67.93 * 0.0092)) = 8.838 Volts

Roughly 9 Volts. Which is well within spec for this type of bulb.

IMPACT runs at 8MHz, which is 8,000,000 Hz or Cycles Per Second. The time take from a lamp being powered, to being powered again is ~110,000 cycles, and the lamp will be powered for ~7,500 cycles during that period.

So if you want the lamps to be brighter, the total period would remain the same, but you would increase the number of cycles the lamp is powered for. Similarly if you want to dim the lamp you would reduce the number of cycles the lamp is powered for.

This is for lamps in normal operation. For the super bright flashes, they stop the multiplexer running completely for a fraction of a second and drive the lamps to be flashed at ~35 Volts. Quickly restarting the multiplexer again before the filament gets too hot and blows the bulb. Though I have been informed by a few techs that the bulbs that were flashed blew quite often anyway.

So from the programmers point of view, that's how multiplexers work, and how they control the lamping in the machine. Quite straight forward really, also has the advantage that AC experiences less power loss than DC, and because each bulb is for a maximum of 1/16 the time, it saves power at the socket too. And on top of that, control of 256 lamps from just 32 wires, saving money on buying copper cable.

From the emulation point of view, however, running a lamp simulation in real time is just possible now, but even my overclocked CPU is maxxed out [on one core] to produce the 60FPS I have the emulator locked to. So while viable, not really the best solution, and was certainly not an option back when Fruit.exe was being brought to fruitiion. I imagine most people now own smartphones more powerful than the PC's the original emulators were written on.

So this is not a knock on Wizard, DT, or Re_A, but now that time has moved on and we have much faster PC's there might be a way. [There is a way to be sure]

Looking from the outside in, and the behaviour of the lamps in the new MFME, I'm guessing that the RMS voltage is being calculated and then used as a multiplier of the bitmap brightness. It has the side effect of wiping the ripple effects out of the lamping, which some will say is a good thing, and for dsiplay on an LCD it probably makes sense to smooth out the brightness. But personally I like to see the ripple effects, as they are part of the personality of the machine and how it looks sat in the dark corner of a room. I am not saying it is better or worse, it's just different, and thats fine and perfectly valid, but just not the look I want to emulate.

The key to the problem is to take the simulation one step further and keep track of the lamp filament temperature. So when powered on it heats up, and when unpowered cools down. The multiplexer is driven fast enough that bulbs are heated before the bulb has a chance to completely cool and stop giving out light.

From this we can ascertain the brightness of the light at any given time, and also colour correct it to look like the real thing.

As a filament heats up it will start off giving out a red light, then orange, then yellow, then white, and then thru shades of blue. Although most tungsten filaments reach equalibrium temperature somewhere in the orange to yellow spectrum. Google "Kelvin colour chart" to see images explaining this more clearly. The super bright flashes will be bright white maybe even slightly blue coloured.

Which later on, when we get on to displaying the results, will become very handy indeed.

And that's about it for part 1. Which will continue when I have had a chance to get the filament heating calculation sorted. Next time I'll get in to how to calculate the lamp temperature and keep track of it in real time.

If any of you have made it this far, well done, feel free to ask questions.

Having a break from FME for a while was the best thing I could've done.

First of all, apologies to Daryl, Trouty, & Dad for being particularly off with them before my hiatus. It's not your fault, I let FME become practically a 2nd job rather than a hobby, and was getting frustrated with everything and everyone.

In the mean time it appears we have a new shiny official MFME to play with which is awesome, and frankly takes the pressure off in a nice way.

I've decided to continue working on Amber and have been tinkering on and off but nothing major. At the very least I want to get IMPACT 100% completed, so every game can be fully emulated and simulated. The online state sharing functions are still really important to me because it makes it more realistic not knowing when a machine is ready to pay, it was also more social as you could chat whilst playing.

I've been working on a ray tracer as a separate project and in doing so have learnt some really useful information about the behaviour of light, delving into the real world physics and having some good ideas for the emulators.

Currently I am working on a full lamp simulation, working from the physical properties of the filament, writing my own physics engine. When complete I can then use them for lamping any tech and they should work as they did IRL with no modification required. So if they dim, or go super bright it will happen automatically based on the physical properties of the light bulb being simulated. I also intend to do the same with the other physical components which should mean that eventually I will have an emulator that can be both 2D and 3D at the same time. 2D is really a 3D image that you can't move around or change perspective. This also means that generating lamp reflections in the cabinet or surrounding objects will be native, along with shadows. And for 2D layouts, I can generate light maps in textures and mix them for playing machines on slower PC's or Indeed Android phones. I have started working on an android emulator but it's nowhere near being ready as I am writing it in Assembler. This will take layouts from the main PC version of Amber and be a play only emulator, no editing apart from basic options.

I also had a go at writing my own machine for IMPACT, and I'll probably release it with the new emu as a demo game, whenever the release happens.