Simulate delay with strobed outputs

[happppp]

Simulate delay with strobed outputs
an 'output' in this case is a MAME output port or pin, such as for a 7segled: output().set_digit_value(index, state);

The problem is really simple. We need to simulate outputs with (inherited) capacitance. There is a too often seen scenario where leds or lamps are strobed and if represented to the emulator user digitally, it will show as a flickering mess. This is the reason I have a custom output-decay handler in many of the handheld drivers.

What needs to be done is a solution in the back-end(HLSL etc?), or MAME output core, that leaves these outputs on for a user-defined interval, by default a few microseconds.

[cuavas]

LEDs don't behave like that though - you can use a high-speed camera
to capture LED multiplexing. LEDs have tens of kHz of bandwidth. LED
multiplexing depends on persistence of vision to no look flickery.
Games that use PWM for incandescent lamp outputs also need better
handling than what we have in MAME currently.

With LEDs fed by PWM, the bandwidth of the LED usually far exceeds the
pulse frequency, and persistence of vision means the brightness
appears proportional to the duty cycle. LEDs are actually a pretty
simple case.

With incandescent lamps you have thermal characteristics of the
filament to consider. As a simplification, the brightness is roughly
proportional to the square of the true RMS voltage applied. You also
get colour temperature shift towards yellow as you reduce the drive.

LCDs are different again, but I don't even pretend to understand them
well enough to give a summary.

A retriggerable monostable like you're suggesting is not a valid
simulation of any of these output devices' behaviours. I'd rather
stick with the flickery mess until such time as we try to model at
least some of these devices properly.

Vas

Quoting hap notifications@github.com:

Simulate delay with strobed outputs
an 'output' in this case is a MAME output port or pin, such as for a
7segled: output().set_digit_value(index, state);

The problem is really simple. We need to simulate outputs with
(inherited) capacitance. There is a too often seen scenario where
leds or lamps are strobed and if represented to the emulator user
digitally, it will show as a flickering mess. This is the reason I
have a custom output-decay handler in many of the handheld drivers.

What needs to be done is a solution in the back-end(HLSL etc?), or
MAME output core, that leaves these outputs on for a user-defined
interval, by default a few microseconds.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#729

[happppp]

Yes you are mostly right, I think in most cases (leds, not lamps!) the capacitance is very small. But that means in practice we'd still need to filter from x KHz to typical 60Hz screen. I refuse to get rid of the workaround in the meantime that would make all handheld drivers unusable.

[happppp]

After a few moments of thinking: I know leaving the workaround in stubbornly has its cons.
pro = me and users can play
con = user is oblivious that there's a workaround. Devs are more reluctant to solve the real problem. It's a shame that in reality I'm the only person currently on the MAMEdev side working on the drivers at hand.

[cuavas]

No you aren't. It fucks up my 8-liners as well. But I have absolutely no clue how I could hack up the artwork system to do variable intensity on an analog output even if I could work out how to create a new output type that took PWM input and produced an intensity output.

[rb6502]

This is a major issue for synths too.

[james-wallace-ghub]

And all the FME stuff could really do with it too, for many reasons,
particularly a dimming and ultrabright effect known to be useful. I know
time based hysteresis is done by some non open tools that could be MAME
friendly if we want to go down that route, but I always wondered how
cleanly that could be done.

On Saturday, 19 March 2016, R. Belmont notifications@github.com wrote:

This is a major issue for synths too.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#729 (comment)

Sent from Gmail Mobile

[GuitarAmber]

Hey all, I was referred here by james.
I have a solution that works quite well for FME, but it's not perfect.

It's best to split the problem into 2 separate things, 1) How to determine the brightness of the bulb / LED, & 2) how to display that effectively.

Part 1 is quite straightforward, though if someone has any decent maths / physics skills, I could make the algorithm more accurate. At the moment I calculate the brightness linearly, but I am almost positive it should be logarithmic.

Part 2, there are various solutions, I'm now using DirectX / HLSL. I'm currently developing my emulator and the more advanced lamping is on the todo list, however I already know what I need to do, and I have dimmed & super bright lamps simulated already.
But displaying artwork on a screen is very subjective, what looks perfect to someone may look poor to another person. But with HLSL / Directx / OpenGL there are many many solutions. If anyone is interested I am willing to discuss it at length, but it's a much bigger subject than it may first appear. It all depends on the level of realism you want, i've been toying with a raytracer and 3D model, though I must admit it's taking some time for all the relevant maths to sink in. But you can create a decent effect quite simply with a standard texture shader.

So, determining the brightness of the bulb...
The method I am describing is based on a standard 8 * 8 matrix, though the principal works just the same for a 16 * 16 matrix by changing a small amount of code.

Let's consider a single bulb attacted to the matrix. Here is the method I use, I know it isn't correct physically, and if anyone here dabbles in physics and would like to chime in, please do. But it does work and looks pretty good.

For each bulb you need to know whether it currently has voltage applied, and how long the voltage has been applied for. If it doesn't have voltage applied, you need to know how long it has been since voltage was last applied.
So I keep 2 counters, TimeOffCycles and TimeOnCycles. I track everything in cpu cycles rather than work it out into seconds.
Then I use 2 values. GlowCycles, and FadeCycles. GlowCycles is the number of clock cycles that elapse in the time it would take the lamp to go from completely off, to fully on if powered continuously. FadeCycles is the number of clock cycles that elapse in the time it would take to go from fully on, to fully off.

FadeCycles is always a bigger value for an incandescent lamp.
The system I developed it on ran at 1.72MHz, and the values I used were; GlowCycles 21000, FadeCycles 111000; How correct this is I don't know, but it looked right to me.

So, using the 4 values (the counters, and the Fade/Glow)...
If the lamp is currently powered (strobe is on, data is on), then Offcycles should be reset to 0, and OnCycles should be incremented. Calculate the brightness by comparing the OnCycles to the GlowCycles. If OnCycles is greater than or equal to GlowCycles then the lamp is at full brightness, otherwise I find the value on a linear scale. I store the Maximum brightness value that the lamp got to while under power as we'll need it later.

If the lamp is currently not powered then I set the brightness on a linear scale of how long the lamp has been off for, from the maximum brightness it got to before. Once the lamp has been off power for greater than OffCycles then the lamp is completely off.

To save CPU cycles I keep a single variable TimeSinceDataChange, which is incremented every instruction with the number of cycles executed. And then add this value to either the OnCycles or OffCyles for each lamp as appropriate at each data write. This saves updating all the lamps every instruction cycle as in FME we deal with up to 512 lamps. I also used to update everything at each change of the MUX Lines but that just seemed to make everything more flickery. How you do this will obviously depend on the specifics of the game hardware.

That's pretty much it. If none of that makes sense please ask away and I'll have another go.
The only improvement I can see would be to calculate the correct curve for the lamp brightness going from off, getting brighter, and then saturating (I'm a bit dodgy with physics, is that the correct term?).

I'll cover part 2 if anyone is still interested.

[Lord-Nightmare]

This is actually useful for VFD DMD displays on arcade and pinball games as well.
As a friend and I discovered when looking at someone's 'Checkpoint' machine ( http://www.ipdb.org/machine.cgi?id=498 ) the DMD needs persistence or it doesn't look right. This is plainly evident on the machine we looked at since the machine used a poorly designed repro LED-based DMD replacement which uses the original display Z80 and ROM, and does NOT emulate the original VFD persistence properly, so the LED-DMD flickers like hell.

A proper DMD replacement would use an FPGA or similar to 'fake' (using pwm) the VFD persistence on each LED. Can use the original z80 code too.

[couriersud]

Just apply a low-pass filter of about 60Hz to 120Hz. That's what our
eyes effectively do:

http://www.nature.com/nature/journal/v299/n5883/abs/299553a0.html
https://en.wikipedia.org/wiki/Flicker_fusion_threshold

For incandescent lamps there are spice models:

https://groups.google.com/forum/#!topic/sci.electronics.cad/I9QfewHAaSI

This one has nice graphs:
www.ee.bgu.ac.il/~pel/pdf-files/conf104.pdf

However, these models are pretty complicated. The following link
discusses a simpler model using two resistors and one capacitor.

http://www.candlepowerforums.com/vb/showthread.php?117367-models-for-incandescent-bulbs

This could easily be done using netlist.Alternatively, one could model
the differential equations given e.g. in conf104.pdf in a time-stepping
approach.

On 03/19/2016 09:01 AM, hap wrote:

Yes you are mostly right, I think in most cases (leds, not lamps!) the
capacitance is very small. But that means in practice we'd still need
to filter from x KHz to typical 60Hz screen. I refuse to get rid of
the workaround in the meantime that would make all handheld drivers
unusable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#729 (comment)

[GuitarAmber]

The low pass filter wont help with persistance.
The pdf with the graphs looks quite useful. But possibly only half the story.
How would that translate for a 12v 0.1W bulb being driven by 48v AC but multiplexed to give 12V rms voltage, rather than 12v DC.
I never got to look into this properly before, I'll have a play with the maths at some point in the next few days / weeks and see what I can come up with.

[Quench0]

Just wondering is this flickering partly due to the rate at which MAME renders layout items when there's no "screen". It defaults to 60hz I think.
I updated the Bally early solid state Pinball driver last year which uses multiplexed 7 segment displays that are updated at 320Hz, when I implemented the blanking signal the displays flickered like crazy. At the time I put it down to a sync issue with Mame rendering the layout display at 60Hz while the driver was updating its display digits at 320Hz. Am I off the mark? Is there some other better solution in this case I've missed?

[couriersud]

How would that translate for a 12v 0.1W bulb being driven by 48v AC but multiplexed to give 12V rms voltage, rather than 12v DC.

If you model the bulb with netlist: perfectly.

[GuitarAmber]

I've been doing some thinking and reading and I think I've realized what's going on.

On a particular FME tech (MPU4) they dim the lamps by playing with the timings of the multiplexer. My solution works in most cases, but not all. I've finally realized why and what they are doing. They are using the multiplexer to apply a square wave rms value on top of the 48v (12v rms). It's only in reading those links that I've really clicked what they were doing with the hardware and why in some cases it didn't work.

Its also helped to make some things clear, and to refresh my memory in this area. So 12v DC is treated the same as 12v rms, that makes sense.

Sorry if I am cluttering the thread, I'm sort of thinking out loud here as I'm now seeing things with a little more clarity.

[GuitarAmber]

Just wondering is this flickering partly due to the rate at which MAME renders layout items when there's no "screen". It defaults to 60hz I think.
I updated the Bally early solid state Pinball driver last year which uses multiplexed 7 segment displays that are updated at 320Hz, when I implemented the blanking signal the displays flickered like crazy. At the time I put it down to a sync issue with Mame rendering the layout display at 60Hz while the driver was updating its display digits at 320Hz. Am I off the mark? Is there some other better solution in this case I've missed?

LED's and Lamps do not go off the moment the power is disconnected, there is a short period where they fade out. The time that takes varies for different LEDs, but a typical value is around 1/20 of a second. This capacitance gives time for the multiplexer to go round and set all the other lamps and get the original lamps under power again before they go out.

If you drive your simulated/emulated lamps directly from the digital signal your lamps will only ever be on (1 / [however many lamp selects]) of the time. The easiest and simplest method of getting round this is to have a single counter. Any time the lamp is powered reset the counter to whatever value. When the lamp is off, decrement the counter (whether you do this in seconds, frames, or clock cycles is up to you). If the counter reaches 0, your lamp is off, any other time the lamp is on.

You'll find the counter value easily with a little trial and error. Too low and lamps will flicker, too high and lamps will stay on as longer than they should.

That's by far the simplest way of doing it, and it'll work just fine, but its not the way it works for real. However it is very much tried and tested. It'll certainly remove the annoying on/off flickering.

[cuavas]

GuitarAmber, what you're saying is just plain not true. LEDs do extinguish pretty much instantaneously - they definitely won't persist for 1/20s unless you actually wire a capacitor across them. You can observe this yourself with a consumer 1,000fps camera pointed at a multiplexed LED display (e.g. the digital LED displays on Yamaha synths and stage pianos). Incandescent lamps fade gradually, but it has nothing to do with capacitance: it's because the filament takes time to physically cool (conducting/radiating heat away). Please stop posting misinformation.