Some emulators are powerful tools, and some are toys for novices. The toys need not conform to the laws laid forth in the following document, which are designed to ensure that those who need power are able to get it without trouble.
An emulator MUST NOT attempt to be both powerful tool and toy. An emulator MUST choose which of these it is, and EXIT this document if it chooses to be a toy.
This document wields capitalized imperative words more flippantly than a typical RFC, as it is endeavouring to formalize design principles in addition to operational principles. Emulator authors ought to exercise less creativity than they historically have in implementing certain core functions.
An emulator MUST implement an EMULUA interface, which is necessary for testing and verification of the emulator stability.
An emulator MUST execute deterministically and exactly reproducibly, down to the very cycle level, on every host system given the same emulator configuration. An emulator SHOULD try execute identically when operating under different configurations, especially with respect to video and audio plugins and the like. Obviously many configurations will alter the behaviour of the emulator and so to that end the emulator MUST write all pertinent information to the movie header. Additionally, the emulator MUST either change configuration or warn the user when loading a savestate with incompatible configurations.
In keeping with the principle of deterministic execution, an emulator MUST have a straightforward internal reset process which yields identically initialized variables and can be called repeatedly. This process MUST be separate from any one-shot emulator host features initialization. In other words, emulation state reset and host state initialization MUST NOT be mixed.
An emulator MUST use a text-based configuration file.
An emulator MUST either write its configuration file to the directory containing the binary which is executing, or permit the specification of alternate configuration files on the command line. As it is impossible to predict which options a user will want to port between different emulator instances or versions, it must fall to the user to control that by direct manipulation of configuration files.
Guidelines of Interest Mostly to TASers
An emulator MUST keep a frame counter, which is to increment at the beginning of each draw cycle (at the end of vblank.) The emulator MUST refer to the first frame as frame 0, which is to begin before the execution of cycle 0.
An emulator MUST change its internal record of input state ONCE AND ONLY ONCE per frame, and this at the beginning of a new frame as defined above. As a contrary example, the emulator would not call through to the operating system to retrieve the current mouse cursor position whenever the game software requests it, but rather retrieve it once per frame and cache it for the duration of the frame.
In order to combat routinely-created bugs in menus, an emulator SHOULD set up all of its menu state in one block of code at the time when the menu is created, analyzing the current emulator state and setting disabled and checkmark states accordingly. For instance, in Win32 this would be done with WM_ENTERMENULOOP.
( Regarding whether configuration gets saved all at once or wherever it gets changed, I am ambiguous. I see virtues to both ways. )
User Interface Guidelines
While admittedly a matter of opinion, to bring order to the unruly thicket of default hotkeys, the following recommendations have been drafted:
An emulator SHOULD use F1 for this and F2 for that.
An emulator MUST have command-line arguments at least implementing the following:
* load state slot (0-9) * play movie file
? OSD? Why do we even do this anymore? ?