Makes it possible to run time-limited OS versions like BeOS DR8.2
(which does not work after 1997-04-01).
This is now also used for deterministic mode (which had already been
hardcoding a 2001-03-24 RTC time).
Also document both flags in the manual.
I happened to get a crash when running with deterministic mode because
an exception occurred right when when the periodic logging timer fired,
and the PC address not valid under the new mapping.
Add a command line option to enable auto grab.
Default to the previous behavior before the auto grab feature was added.
Add a debugger command to enable or disable auto grab.
Notes:
Auto grab mouse currently only works for graphics controllers and guest
OSs that use a hardware cursor and only if the emulation sets
cursor_dirty to true (i.e. not emulation that uses cursor_ovl_cb).
Add --help-all option.
Move emulation options to an empty named subcommand.
Show defaults for --workingdir and --bootrom.
If --bootrom is not specified then validate the default.
Put them in a separate option group named "execution mode" and specify that only one of them can be selected.
CLI11 will handle the error message if the user attempts to set both options.
Read ROM file once.
Identify 68K and New World ROMs.
Improve identification of Old World ROMs.
Perform checksum checks.
Identify the ROM even if the user specifies a machine option.
This is an alternative method for specifying the working directory.
Normally, the user would change the directory before executing dingusppc to set the working directory.
The working directory is the default location for files and sockets used by dingusppc (the bootrom file, symbols file, nvram, pram, serial port sockets, logs, etc.)
Replace it wth an explicit opcode parameter that is passed around. That
is both slightly easier to reason about (to trace where it comes from)
and slightly faster, since it can be read from a register.
On my machine takes booting to "Welcome to Macintosh" being output in
a verbose boot of Mac OS X 10.2.8 from 31.8s to 30.6s (average of 5
runs, measured using deterministic mode and looking at when execution
reaches PC 0x90004a88).
The previous approach of traversing the machine and its device tree
at startup to register CLI11 options was not working for dynamically
registered devices like PCI cards. This meant that options like
gfxmem_size or mon_id from the video cards could not be set.
Switch to instead registering in MachineFactory a hook function that
provides CLI flag values. We can call it when registering any property,
whether at startup or dynamically.
Adds support for a --deterministic command-line option that makes
repeated runs the same:
- Keyboard and mouse input is ignored
- The sound server does a periodic pull from the DMA channel (so that
it gets drained), but only does so via a periodic timer (instead of
being driven by a cubeb callback, which could arrive at different
times)
- Disk image writes are disabled (reads of a modified area still
work via an in-memory copy)
- NVRAM writes are disabled
- The current time that ViaCuda initializes the guest OS is always the
same.
This makes execution exactly the same each time, which should
make debugging of more subtle issues easier.
To validate that the deterministic mode is working, I've added a
periodic log of the current "time" (measured in cycle count), PC
and opcode. When comparing two runs with --log-no-uptime, the generated
log files are identical.
Shutdown will enter the debugger or quit depending on the execution mode.
Quit is different from shutdown since it is triggered outside the guest by using the host Quit menu item.
Allow the verbosity to be adjusted.
Allow logging to be sent to stderr even when running in interpreter mode.
Allow uptime (time since program start) to be disabled. This makes it
easier to compare logs across successive runs.
Keeps track of instructions (including operands) that are executed,
to see if there are any hotspots that could be optimized or fastpaths
that should be added.
Also adds a mode where CPU profiler data is periodically output, to
make it easier to get at these instruction counts during startup.
The SIGABRT handler is not invoked by the abort() call in the loguru
fatal handler, but either way it's not necessary (it does its own abort).
Switch to explicitly cleaning up the machine object, which as a side
effect in the destructor chain will persist the NVRAM.