16 Application User Interface
The standard CEF user interface is defined in this section. The form of the interface is not described, only its base functionality. Extensions to the base functionality are allowed, and expected. The operations required are:
The user must be able to assemble, via the CPU object, both an external file and input. Output may be directed to memory or to an external file.
The user must be able to set a breakpoint on physical and virtual memory addresses.
The user must be able to write to any component which accepts writes. He must be able to specify the address, value, and size of the write.
The user must be able to disassemble an address, or range of addresses, to the screen or to a file. The disassembly must be in a form which is syntactically acceptable by the Assembler.
The user must be able to read from any component which accepts reads. He must be able to specify the address or address range. The reads must be non-destructive. The output may be directed to the screen (classic examine), or to an external file (dump).
The user must be able to exit the emulator when he desires.
The emulator must provide some form of instructions about its operation.
The user must be able to restore the state and/or contents of any component from an external file created by the Save operation.
The user must be able to halt the CPU, as if a hardware halt.
The user must be able to asynchronously pause the CPU.
The user must be able to turn profiling on and off for any or all components. When on, the emulator must provide statistics on the usage of the components for whom profiling is enabled.
The user must be able to reset any component or the entire environment. There must be a means for reseting the CPU to a valid execution state should it not be in one (such as halted).
The user must be able to start or resume CPU execution as desired, assuming the CPU is in a valid execution state (not halted, for instance).
The user must be able to save the state and/or contents of any component, or of the entire environment to an external file for later loading.
The user must be able to see a list of breakpoints and watches.
The user must be able to execute a single instruction at the current CPU context. This can be of two modes: INTO means that no more than one instruction will execute. OVER means that execution continues until it returns to the next logical instruction.
The user must be able to log the execution trail to a file for later analysis.
The user must be able to set breakpoints on changed component states, specifically (at a minimum) memory contents, and CPU register contents.
CEF Emulator files
Files with an extension of ".cef" are supported to provide high-level definitions of emulators. These files need not be supported, but if they are then they must conform to the description in this section.
The files are plain-text files which contain space-delimited tokens defining commands and parameters. White space is ignored except as a means of separating tokens. In order to use white space for other means, it must be enclosed within a quoted token. A quoted token starts with a quote and ends when the same quote character is encountered again. Everything within the quotes, and the quote characters themselves, is considered part of the token. The double quote character (") and single quote (') are valid quote characters. One type of quote can be enclosed within a token delimited by the other type of quote. Since either may be used to quote a token, the other may be enclosed as literal text.
A given implementation may add additional commands to its definition file processing, but must support those defined in the section Emulator Definition Files. It would be wise for such extensions to use command tokens containing dollar signs ($) or underscores (_) to avoid conflicts with future extensions to this specification, as those characters will never be used in anything required by future specifications. These are the required commands that supported by CEF Emulator Files.