This can freeze for reasons I didn't completely root cause. The MWE
leading to this was made by @Calamari, is very dependent on factors I
haven't completely characterized, but includes having the DMA driver,
doing a world switch; and seems to require some timers (via gray engine)
and stack usage, but I'm not clear on the role of that.
* Interrupt now at level 15 so it can work in the input timer callback
* Remember last raw/conv/dots and expose unstable API to use it via new
include <gint/drivers/touch.h>
* Put number of touches in the structures
This should work on Windows Vista onwards. By specifying Windows OS 1.0
descriptors announcing compatibility with WinUSB, we get it as a driver
plug-and-play style with no manual intervention (e.g. no Zadig).
From there libusb can enumerate the device, which is awesome.
key_event_t is now 8 bytes instead of 4, a change that was doomed to
happen anyway to deal with touch input (where it's not clear either
whether 8 bytes will be enough for double touch).
* Add a new HWCALC value HWCALC_FXCG100, detected based on being on an
Area-3 RAM model and having OS version that's either less than 3 or
3 and built after January 2025.
* Disable the _ostk heap arena, as the region might simply not exist,
and improve the VRAM allocation code to account for this better than
the hardcoded macro previously in place for the fx-CP 400.
* Disable gint_osmenu() which can't work with MPM right now.
* Add BFile_FindFirst() and GetVRAMAddress() syscalls.
If none of the HH2_*() macros are used, the binary will show up as its
own filename instead of random garbage.
If HH2_NAME() is used the metadata will be read, and the binary format
requires that all fields by specified. Using only a subset of the macros
is invalid, but not reported.
