- Define a draft of the video interface
- Implement that dragt for CG for a single mode
* Includes stub of brightness setting from disassembling 3.60
- Use the video interface to show visual feedback on GDB on CG
Using the video interface avoids directly linking into a driver, which
will serve modularity in gint 3.
It's not super useful as a feature but it means that a naive "continue"
after e.g. a segfault will kill the program and not confusingly go into
an infinite loop.
The user can still gdb_start() + gdb_main(NULL) manually, which allows
e.g. early setup of breakpoints. The start_on_except mechanism is the
lazier method where we just run the add-in normally and start fxsdk gdb
on the PC *after* a crash occurs.
It is guaranteed by the driver model that drivers are powered on when
gint is active. Sharing the driver isn't too useful because we can't
remote debug in the OS world anyway, there's no USB driver there.
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.
Nothing interesting in this commit, just moving files around, making
sure every target compiles every file, and controlling with macros
instead.
Basic support for fxg3a target in CMakeLists.txt, cmake/FindGint.cmake,
giteapc.make and include/gint/config.h.in. The rest is forgettable.
This is the first of many steps designed to reduce gint's reliance on
the FX9860G and FXCG50 macros by describing the compile target more
symbolically. The goal is to allow both for g3a compilation of fx-API
code and for a potential CP port.
* Honor dwindow settings immediately (avoids useless dline() calls)
* Bound to ymin/ymax instead of doing many useless cut computations
* Remove the need for floating-point operations and division
It used to be a flexible array member because in the old days fxconv
could only output a fixed set of bytes, so any referencing was out the
question. Nowadays fxconv can output pretty much anything. Separating
the data pointer will be useful for PythonExtra to expose it as a Python
bytes() or bytearray() object while using the gint API.
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.
Lephe
Sylvain PILLOT
redoste