ROM emulation, why is it so important?

Why is it so important to run the actual table roms under emulation rather than programming the rules etc themselves? I can see that it may save time but is it at the expense of performance? in response to some question about performance sometimes FS answer has been ' don't forget we are running rom emulation too ', and this has held back the development of the 3ds version if I remember correctly, the 3ds not being powerful enough to run the emulation at full speed. I'm guessing I am wrong about this, thats why I'm asking. Anyone care to enlighten me?

Mostly it's for accuracy. Most of the tables are so complicated it would take months to "script" them to behave like the real table. And even then we would miss things we didn't know the real table does. The older tables this was less of an issue because they weren't as complicated. The new ones are extremely complicated.

We also would have the issue of getting the DMD animations to match the original table.

Our goal is to reproduce the tables as exact as we can. Emulating the ROM is the only way to make it precise.

As for performance, we have some ideas on improving it, and hopfully getting it running fine on the 3DS.

Thanks for the quick reply Mike, I did say I was probably wrong!

You're welcome.

Mike, so when you're programming the table, you simply have to say "this is the ____ light" and then let the ROM decide when to flash the light? Definitely sounds easier than having to find every instance of when that light may flash in order to get it working properly.

I couldn't imagine trying to code a modern table's ruleset from scratch, such as TOTAN or MM, and I'm a coder too.

Gord Lacey said:

Mike, so when you're programming the table, you simply have to say "this is the ____ light" and then let the ROM decide when to flash the light? Definitely sounds easier than having to find every instance of when that light may flash in order to get it working properly.

Click to expand...

Probably not that simple. The challenge in emulating ROMs (of any description, not just pinball controllers) is that the ROM is expecting to find certain hardware at certain addresses, and memory locations laid out in a certain way, and certain instruction sets available, and so forth. When you emulate, you have to provide convincing illusions of all this "hardware" and "memory" and "instruction sets" in software. Basically, you're trying to fool the ROM into thinking that it really is in its native environment, and that signal it just received is really from the left inlane rollover coming in on input port whatever, etc.

What you end up with is a framework that provides the right sort of (simulated) environment for the ROM to run in. This framework passes signals to and from the ROM as well as decides how to interpret them. For example, the framework may tell the ROM "the ball has activated the left inlane rollover", and the ROM says "OK, that completes the 8th set of F-I-R-E, so DMD, you display the FIRE animation with the message 'Video Mode is Lit', and I'll set this flag over here so that the next time I receive the message 'The ball is in Merlin's Saucer', I'll start the video mode." The framework sees the outgoing signal for DMD animation and runs whatever code is necessary for the real processor on your device to display the animation.

Multiply this by all the messages and signals that are needed to account for all events of interest on the table, consider that perhaps events are occurring simultaneously during multiballs, and you can see this gets really complex really fast. And, if at any time the ROM encounters something unexpected (because you left something out of your framework, or you did not quite simulate the environment just exactly right), weirdness may occur. Weirdness may range from completely unnoticeable errors to minor glitches to the ROM crashing.

I used to have to do a similar sort of thing to get card access systems, fire alarm systems and other hardware to talk to video camera systems in my previous life as a security engineer. While it's not nearly as exciting (or complicated) as emulating pinball tables, it gives me an appreciation for what FarSight must be going through to get this working.

I wonder if it's possible to adjust the settings using the FS ROM emulation? Would be a nice feature to add in the future, if it can be done.

EDIT: I just noticed there's a thread about this right on the same page. Heh.

I'd rather get two fully emulated tables with a few bugs every month to a month and a half than two fully scripted tables with a plethora of gameplay discrepancies every six months. How about everyone else?

PiN WiZ said:

I'd rather get two fully emulated tables with a few bugs every month to a month and a half than two fully scripted tables with a plethora of gameplay discrepancies every six months. How about everyone else?

Click to expand...

+1000 If making this game was as easy as some people think it is, it would have been done years ago.

Steve Ellenoff (want to give him credit) is the one who wrote/writes our emulation "engine". His code handles all the lower level side of it. Then it gives me the data I need in a simpler form. Mainly it tells me which lamps, flashers and solenoids are on/off, which sounds to play, what the DMD looks like this frame, and I tell it which switches are on/off. So say the ball rolls over a wire switch that is #22, I tell the emulator that #22 is on (then later off when the ball rolls off it), and the emulator may tell me that Lamp 34 is on, so I modify that lamp to appear on, it may also add some score, and/or play some DMD sequence and trigger off a sound effect.

Some parts become more complicated. Mainly the non generic type parts. Brides of Pinbot's head that rotates, the magic chest on Theater, etc. Those require some special code to make them work the way the real table does. They still use inputs/outputs form the emulator, but it's just more compliated than say a pop bumper that the metal ring part moves up and down when it fires.

Course the one issue we come into with the emulation is that the real tables have bugs in them...and we end up emulating those bugs as well. And in cases like Theater, the inability to hold scores over 9,999,999,999.

Thanks for the info Mike.

I fully agree that emulation is the only way to handle these latter-day games. People are still finding new things/bugs in these tables after all these years, and no amount of scripting can really ever get all the nuances and exact timings required.

Just out of interest, approximately what percentage of a 360's total CPU load does the emulation typically take up?

(I know it's a tough question, given the multiple cores and threading...)

Mike, what are the chances of emulation speed/efficiency approving and being applied retroactively? By that I mean, I'm sure as more tables get released the emulator becomes better at doing what it does (either by simply doing things faster, or just dropping/rescripting redundant tasks), but would that particular (MPU-specific) engine be used across different machines or are they table-specific? Are they platform-specific as well or would an improvement to, say, the engine to speed it up on iOS devices be implemented on Android, console and PC versions? I'd imagine so (to maintain uniformity) but you're the guy who'd know!

Actually, one more thing: Would it be possible to have a combination of the script-based engine running in conjunction with the emulation? So that if there's something particularly hard/high-load to emulate, just write a script and insert a call in the ROM to run it, then return whatever values needed back for the emulation to continue.

Apologies for fully nerding out on you here, I'm just genuinely curious. If there's anything that's meant for internal eyes only, just say so... don't feel obligated to answer in the slightest


(And perhaps a quick one on the side... what would be the chances of having cut-down tools used by you guys available to developers to create their own tables? Either for fan-made games on PC or potentially as "free" DLC by studios to promote things like movies. Could be an interesting idea for getting the game out there to a wider audience. Imagine an Avengers pinball game on the Farsight engine!)

Butterkins said:

Thanks for the info Mike.

I fully agree that emulation is the only way to handle these latter-day games. People are still finding new things/bugs in these tables after all these years, and no amount of scripting can really ever get all the nuances and exact timings required.

Just out of interest, approximately what percentage of a 360's total CPU load does the emulation typically take up?

(I know it's a tough question, given the multiple cores and threading...)

Click to expand...

Physics and Emulation are the 2 largest performance hogs on CPU. While we could have multi-threaded it to make use of the Xbox 360's Tri core CPU, it didn't make sense to me to do that. I figure if the game won't run on a single core at 3 GHz, there was no way it would run on a phone with a 1 GHz single core processor.

I don't know the exact amount anymore, but early on when I did some performance testing we were using something like less than 25-30% of a single core of the CPU on the Xbox 360.

Shaneus said:

Mike, what are the chances of emulation speed/efficiency approving and being applied retroactively? By that I mean, I'm sure as more tables get released the emulator becomes better at doing what it does (either by simply doing things faster, or just dropping/rescripting redundant tasks), but would that particular (MPU-specific) engine be used across different machines or are they table-specific? Are they platform-specific as well or would an improvement to, say, the engine to speed it up on iOS devices be implemented on Android, console and PC versions? I'd imagine so (to maintain uniformity) but you're the guy who'd know!

Actually, one more thing: Would it be possible to have a combination of the script-based engine running in conjunction with the emulation? So that if there's something particularly hard/high-load to emulate, just write a script and insert a call in the ROM to run it, then return whatever values needed back for the emulation to continue.

Apologies for fully nerding out on you here, I'm just genuinely curious. If there's anything that's meant for internal eyes only, just say so... don't feel obligated to answer in the slightest


(And perhaps a quick one on the side... what would be the chances of having cut-down tools used by you guys available to developers to create their own tables? Either for fan-made games on PC or potentially as "free" DLC by studios to promote things like movies. Could be an interesting idea for getting the game out there to a wider audience. Imagine an Avengers pinball game on the Farsight engine!)

Click to expand...

I don't think I can give any details about optimization's. Most optimization's would be across all platforms, even though it might no be necessary. That way each platform has a unified code base. This reduces platform specific bugs and problems.

As for an editor or other tools, I don't really know. That's more a question for Business/Management to answer.

Thanks for providing that info! Makes sense about the unified fixes.

Mike while we are on subject of emulation. How will emulation change if you guys start making EM tables that didn't have any rom/computer in them? Would you have to do it old way and manually make script or oh I dunno create virtual wires following the table's wiring diagrams and let it work the table somehow?

Not sure how we are going to do EM tables. Most likely I would need to see how a few of them worked to see if there is a common way of handling it. On the other hand EM tables are usually not that complicated so scripting would also work.

When we get to the point of doing those, then I'll have to figure out a solution.

World's biggest if-then-else statement

No EM's in the foreseeable future then? Well that (luckily, em's...meh) lays to rest some rumours about upcoming tables.