AdbKeyboard would copy the event into its own fields and set the
changed field, so that we could return the event when register was 0.
However, if a subsequent event was received before ADB polling, the
previous event would be overwritten and lost.
Fix this by maintaining a queue of events, so that we can return
everything since the last poll.
We were using an empty value on the second byte of the ADB keyboard
register 0, but that maps to the "a" key. This manifested itself
as the Key Caps DA never showing the "a" key as being down.
Switch to a non-existent key for the second byte.
Allows different implementations for different platforms (the JS
build relies on browser APIs to stream disk images over the network).
Setting aside the JS build, this also reduces some code duplication.
postinit_devices() may cause additional devices to be registered
(e.g. PCI hosts will register their cards). We were not calling
device_postinit on those devices, because the iterator over the
device map was set up at the start of the loop.
Keep looping until we've actually initialized all devices in the map.
Otherwise if pull_data is called again, it will think that it still
has data available in the buffer (rem_len will be non-zero) and
random data at the buffer location will be returned.
This manifested itself as noise being played back in the JS
implementation of the SoundServer. The cubeb implementation was not
affected because it stops polling once it's told it has no more
data in the buffer. Both approaches are valid (the JS version pads
data with silence), and the DMA buffer should support both.
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.
As part of adding ADB keyboard support (#56), we're now running into
conflicts between the guest and host OS keyboard shortcuts when running
on macOS hosts.
SDL2 unconditionally adds some menu items to the "Window" menu, and
there are built-in ones too. As a workaround, we now iterate over all
menu items are swap out command for control, since the the latter is
generally unused in classic Mac OS.
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/
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.
The simplest solution is to cut the aperture size by the amount
of video RAM installed. This way, accesses to the big-endian
aperture located above the installed VRAM will be catched and
reported by the MMU.