Currently, several plugins test for a specific version number to be set
in the config; if the version number is not present, then such plugins
initialize themselves with default parameters, completely ignoring any
parameters that had been set previously.
Example:
Input Warning: Missing or incompatible config section 'Input-SDL-Control1'. Clearing.
This behavior makes command-line plugin parameters largely unusable
until the configuration file has been written to (with an appropriate
"version" parameter).
To fix this, parse plugin parameters in another phase: after loading the
plugins but before attaching them to the core. This allows plugins to
load their own defaults before the command-line parameters are overlaid.
Plugins should be able to handle this; the operation is similar to how
mupen64plus-gui loads plugins to get defaults, allows the user to modify
the parameters, and then attaches the plugins to the core.
Zero arguments: disassemble one instruction at the current PC
One argument (address): disassemble one instruction at the address
Two arguments (address, size): disassemble 'size' instructions at 'address'
Three arguments (address, size, flags): disassemble 'size' instructions at 'address'
- If bit-3 is set (i.e. & 0x04): also print binary representation of instructions
- If bit-2 is set (i.e. & 0x02): prefix each instruction with its memory address
- If bit-1 is set (i.e. & 0x01): prefix each instruction with an index from the start of disassembly
Currently, plugins frequently call ConfigSaveSection(), which results in
the configuration being rewritten. I intend to submit patches to remove
these calls.
In exchange, the front-end should save the configuration at the latest
safe opportunity, to capture any changes before most chances of crashes,
power outages, kill -9, etc.
The '--nosaveoptions' option does not work currently, due to various
reasons.
1. The core saves its configuration when loaded (addressed in a separate
PR).
2. Plugins often save their configuration (to be addresses separately,
if this change is acceptable).
3. The UI does not parse --nosaveoptions early enough to avoid saving
the configuration (addressed in this patch).
This does not fully make --nosaveoptions work, but it is an incremental
improvement.
Definition of DD IPL rom and disk is done through the mupen64plus.cfg
file as follow:
[64DD]
IPL-ROM="path/to/64DD_IPL_ROM.bin"
Disk="path/to/64DDDisk.ndd"
Setting an empty IPL-ROM disable the 64DD.
Setting an empty Disk acts as if the 64DD had no disk plugged in.
You can also specify these at program startup using command-line
arguments --dd-ipl-rom and --dd-disk.
Definition of GB carts loaded inside transferpak is done through the
mupen64plus.cfg file as follow :
[TransferPak]
GB-rom-1 = "path/to/gb_rom.gb"
GB-ram-1 = "path/to/gb_rom.sav"
GB-rom-2 ...
GB-ram-2 ...
Setting an empty GB ROM acts as if GB cart was removed form TransferPak.
Setting an empty GB RAM let the Core generate a blank save file.
These parameters are modifiable during emulator execution. You just need
to trigger the GB cart change button, and these parameters will be
reloaded.
You can also specify these at program startup using command-line
arguments --gb-{rom,ram}-{1,2,3,4}
