* 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.
* Set -flto
* Use gcc-ar to build the archive so the LTO plugin is loaded and LTO
sections aren't stripped off the object files
* Slightly conservative KEEP()s in the linker script (not required but
I'm paranoid)
* Make the drivers __attribute__((externall_visible)) so they are
generated by the link-time back-end and not left in the archive
* Remove the unused isappli/optnum parameters of main, which have been
unused for years, are irrelevant on fx-CG and lead to a link-time
warning with LTO. I'll add APIs to access them later.
Features will come in slowly while I restructure for gint 3. With this
third big target for gint, the legacy aspects of gint 2's structure and
API are getting felt, so a major revision will be in order.
See the TODO file at this commit for info on what works and not.
Not changing much for now, just distilling them into hardware/OS/render
macros. Later on the rendering stuff will become more dynamic and down
the line I want to unify the APIs more.
Instead of using GetKeyWait(), we directly call into an internal OS
function, which avoids the need to press a key before we can redraw over
the OS banner and VRAM when coming back. The disassembly to locate the
function was developed by Dr-Carlos.
We still have to redraw when coming back; getkey() will do it by
dupdate() by default, and it that's not a possibility for the
application an option to receive a special event and handle it manually
is provided.
This workaround using a gint_call_t with an odd address is not realy the
cleanest idea but it helps keep the existing intc_generic_handler in
the 32 bytes size limit of the VBR space.
* Add options to RESET, go to menu, or abort()
* Define weak symbols for driver functions so that low-level debugging
add-ins can be linked with minimal drivers (CPU/INTC/MMU)
* Create a heap arena over the OS stack, large enough to hold two VRAMs
as was previously done, unless GINT_NO_OS_STACK is set at compile
time. (This replaces GINT_USER_VRAM.)
* Allocate a single VRAM in the heap at startup.
* Use double buffering by default as triple buffering is almost entirely
useless. dudpate() waits if both VRAMs are identical to prevent
corruption, but this can be bypassed with R61524 functions as usual.
This adds about 180 kB of heap data to any add-in using default
settings.
I saw a crash with the 12 kB stack. Added an error message to diagnose
further similar issues, and bumbed the stack to 14 kB. That's a lot of
space just for BFile but stability is queen... :x