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.
This reverts commit b0c4e6fd2f.
After investigation, this is related to builtin functions. Using
-fno-builtin is a less invasive way to solve the problem. However this
appears to be a bug [1]; in theory fat LTO objects should solve that. I
will handle this matter at the fxSDK level by adding -fno-builtin right
and experimenting with the bugfix in binutils 2.43.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
As of now (fxSDK 2.11), this flag is set globally by the fxSDK, so this
change doesn't have an immediate effect. However, I've been
experimenting with removing -ffreestanding at the global level to allow
applications to build with the hosted C++ library (which isn't fully
supported by has many supported features, like containers, that aren't
available in free-standing mode).
Without -ffreestanding, LTO makes weird decisions and ends up pruning
way too many symbols from libraries, leading to undefined references for
symbols provided by the standard library. Here is a minimal example.
---
% cat abort.c
void abort(void)
{
__builtin_unreachable();
}
% cat main.c
extern void abort(void);
int start(void)
{
abort();
return 0;
}
% cat sh-min.x
ENTRY(_start)
OUTPUT_FORMAT(elf32-sh)
SECTIONS {
. = 0x1000;
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss) }
}
% sh-elf-gcc -flto -nostdlib -ffreestanding -c abort.c -o abort.o
% sh-elf-gcc-ar rcs abort.a abort.o
% sh-elf-gcc -flto -nostdlib -c main.c -o main.o
% sh-elf-gcc -flto -nostdlib -save-temps main.o -o main -T ./sh-min.x abort.a -lgcc
ld: ./main.ltrans0.ltrans.o: in function `_start':
<artificial>:(.text+0xc): undefined reference to `_abort'
---
To solve the bug in this example, add -ffreestanding when making main.o.
I haven't been able to sufficiently dump/introspect intermediate files
to understand what's happening yet. It's also unclear whether the fix is
clean since LTO normally requires all files to be built with the same
settings, so adding -ffreestanding to gint but not the add-in seems
suspicious. There is, however, an inherent incompatibility in the
conjunction of (1) building kernels with -ffreestanding, (2) building
add-ins that use the C++ library thus require -fhosted, and (3) only
linking objects files built with the same options.
