The device memory interface provides devices with the capability of creating address spaces, to which address maps can be associated. It’s used for any device that provides a (logically) address/data bus other devices can be connected to. It’s mainly, but not only, cpus.
The interface allows for up to four address spaces, numbered 0-3, with symbolic names associated to them in emumem.h for historical reasons.
|Numeric ID||Symbolic ID||Symbolic name|
The device must override that method to provide, for each of the four address spaces, either an address_space_config describing the space’s configucation or nullptr if the space is not to be created.
The has_configured_map method allows to test in the memory_space_config method whether an address_map has been associated with a given space. That allows to implement optional memory spaces, such as AS_DECRYPTED_OPCODES in certain cpu cores. The parameterless version tests for AS_PROGRAM/AS_0.
3. Associating maps to spaces¶
Associating maps to spaces is done at the machine config level, after the device declaration.
The generic macro and the four specific ones associate a map to a given space. Address maps associated to non-existing spaces are ignored (no warning given). devcpu.h defines MCFG_CPU_*_MAP aliases to the specific macros.
That macro removes a memory map associated to a given space. Useful when removing a map for an optional space in a machine config derivative.
4. Accessing the spaces¶
Returns a given address space post-initialization. The parameterless version tests for AS_PROGRAM/AS_0. Aborts if the space doesn’t exist.
Indicates whether a given space actually exists. The parameterless version tests for AS_PROGRAM/AS_0.
5. Weird/to deprecate stuff¶
These methods override how the debugger accesses memory for a cpu. Avoid them if you can. Otherwise, prepare for heavy-duty spelunking in complicated code.
If really required, should probably be part of cpu_device directly.