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.
Add new GamepadButton enum with bits corresponding to AppleJack button bits.
Both the AppleJack controller and the SDL GameController coincidentally define
one d-pad, two shoulder buttons, four face buttons, and three system buttons.
This makes mapping modern game controllers to the AppleJack straightforward.
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.
Add absolute coordinates for tablets. Absolute coordinates is relative to window so it can't work for multiple displays? Doesn't work for single display without mouse driver modification.
Add arbitrary number of buttons. Previously, only one mouse button was supported.
Add arbitrary number of bits. Previously, only 7 bits per axis was supported which is good enough for relative movement but not absolute movement.
There are cases where when it's necessary (e.g. given uninitialized NVRAM,
the Beige G3 with the 10.2 install CD inserted will update the boot
device and restart to boot from it).
Restart support was done by wrapping the ppc_exec function in a loop and
checking for a restart power off reason. We also need to disconnect all
event listeners, since they will be recreated when the machine is
re-initialized.
Typing Control-C in Terminal app causes an interrupt signal that should enter the DPPC debugger but this only worked once since the signal handler never returned. Even if the signal handler reenabled the signal somehow, it calls enter_debugger recursively which is strange since the earlier calls to enter_debugger would never return.
Now the signal handler just sets a flag (power_on) which can be used to exit any loop (emulator loops, stepping loops, disassembly loops, dumping loops).
Main always calls enter_debugger now which calls the ppc_exec loop. The power_on flag will exit the ppc_exec loop to return to the debugger. Recursion of enter_debugger is eliminated except for calls to loguru's ABORT_F.
An enum power_off_reason is used to indicate why the power_on flag is set to false and to determine what happens next.
Take 2 of 587eb48f61. We now implement
this at the SDL level, which works cross-platform and allows us to
ensure that the guest never gets the Control-G event.
Besides generating KeyboardEvents in the SDL event handler and
returning the key state in the register 0 reads of the AdbKeyboard
device, we also needed to generalize the ADB bus polling a bit. We now
check all devices that have the service request bit set, instead of
hardcoding the mouse.
The SDL key event -> ADB raw key code mapping is based on BasiliskII/
SheepShaver's, but cleaned up a bit.
Result of running IWYU (https://include-what-you-use.org/) and
applying most of the suggestions about unncessary includes and
forward declarations.
Was motivated by observing that <thread> was being included in
ppcopcodes.cpp even though it was unused (found while researching
the use of threads), but seems generally good to help with build
times and correctness.
While Emscripten has an SDL compabtility layer, it assumes that the
code is executing in the main browser process (and thus has access to
them DOM). The Infinite Mac project runs emulators in a worker thread
(for better performance) and has a custom API for the display, sound,
input, etc. Similarly, it does not need the cross-platform sound support
from cubeb, there there is a sound API as well.
This commit makes SDL (*_sdl.cpp) and cubeb-based (*_cubeb.cpp) code be
skipped when targeting Emscripten, and instead *_js.cpp files are used
instead (this is the cross-platform convention used by Chromium[^1], and
could be extended for other targets).
For hostevents.cpp and soundserver.cpp the entire file was replaced,
whereas for videoctrl.cpp there was enough shared logic that it was
kept, and the platform-specific bits were moved behind a Display class
that can have per-platform implementations. For cases where we need
additional private fields in the platform-specific classes, we use
a PIMPL pattern.
The *_js.cpp files with implementations are not included in this
commit, since they are closely tied to the Infinite Mac project, and
will live in its fork of DingusPPC.
[^1]: https://www.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development/
Use explicit cast when converting large integer types to smaller integer types when it is known that the most significant bytes are not required.
For pcidevice, check the ROM file size before casting to int. We'll allow expansion ROM sizes up to 4MB but usually they are 64K, sometimes 128K, rarely 256K.
for machinefactory, change the type to size_t so that it can correctly get the size of files that are larger than 4GB; it already checks the file size is 4MB before we need to cast to uint32_t.
For floppyimg, check the image size before casting to int. For raw images, only allow files up to 2MB. For DiskCopy42 images, it already checks the file size, so do the cast after that.
Fixed an issue where TBR doesn't have full 64-bit range. The original calculation was 64 bit and ended with a ÷ 10^9. This means the max for the upper 32 bits is 2^32/10^9 = 4. The solution is to use a multiplication method that supports a 96 bit product. core/mathutils.h contains functions for that. TBR driving frequency is assumed to be less than 1 GHz. Some minor modification is required for future > 1 GHz support.
