Search titles only
By:
Home
Forums
New posts
Search forums
Articles
New articles
New comments
Search articles
Pinball DB
Pinball Tables
Pinball Games
What's new
New posts
New articles
New profile posts
New article comments
Latest activity
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Welcome Back to Digital Pinball Fans -
please read this first
For latest updates, follow Digital Pinball Fans on
Facebook
and
Twitter
Home
Forums
Farsight Studios
The Pinball Arcade / Farsight Studios
ROM emulation, why is it so important?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Sean DonCarlos" data-source="post: 4572" data-attributes="member: 152"><p>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. </p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="Sean DonCarlos, post: 4572, member: 152"] 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. [/QUOTE]
Verification
Post reply
Members online
No members online now.
Home
Forums
Farsight Studios
The Pinball Arcade / Farsight Studios
ROM emulation, why is it so important?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Accept
Learn more…
Top