The change matches the way that I/O register structures are defined in other headers. The names are defined as "struct", instead of as "pointer to struct".
All but one TGI drivers didn't use IRQs. Especially when the TGI driver kernel was the only .interruptor this meant quite some unnecessary overhead because it pulled in the whole IRQ infrastructure.
The one driver using IRQs (the graphics driver for the 160x102x16 mode on the Lynx) now uses a library reference to set up a JMP to its IRQ handler.
So far conio.h included the target header to get the CH_... and COLOR_... macros. However tgi.h never did the same to get the TGI_COLOR_... macros. And some time ago the JOY_..._MASK macros moved from joystick.h into the target header yet joystick.h didn't include the target header.
Why wasn't that issue detected so far? Because about every program using TGI and/or the joystick uses CONIO too and therefore includes the target header that way.
However, conceptually it's clean to factor out the target header inclusion and have tgi.h and joystick.h do it like conio.h.
Apart from that user code may make direct use of target.h too.
All but one joystick drivers didn't use IRQs. Espsecially when the joystick driver kernel was the only .interruptor this meant quite some unnecessary overhead because it pulled in the whole IRQ infrastructure.
I was told that the one driver using IRQs (the DXS/HIT-4 Player joystick driver for the C64) can be reworked to not do it. Until this is done that driver is defunct.
The Apple II linker configs don't define symbols for the STARTP segment anymore. There refer to the load/start address in the same way the executable file header does.
The RAM memory area symbols are referred by the startup code. The 64k and 128k variant say "for assembler" so it may be not necessary to do that there. However given the "limited" state of documentation for the target I don't assign too much value to those statements.
Additionally it's unclear to me why two variants provide symbols for the ROM memory.
The Apple II hires screen buffer is located at $2000 (and can't be moved). The usual way to get along with this is to load the cc65 program above the hires screen buffer at $4000. However, that means that it becomes difficult to make good use of the memory below the hires screen buffer. The simplest approach is to add that memory to the heap. But there are programs containing just lots of code and not much data. One could think of moving the code to the area below the hires screen after loading (like it is done with the code for the language card). But if the program is really large (and already contains code to be moved to the language card) it won't just fit into memory in the first place.
The alternative is to load the program at the usual $803 and have it "cover" the hires screen buffer. Of course the part of the program that actually "covers" the hires screen buffer mustn't contain anything necessary for the program. The downside of this approach is that the program file on disk contains 8kB that can't be used by the program. But instead of just containing zeros the program can as well contain a hires screen picture that can be displayed right after startup.
Now the user can have code loaded below the hires screen buffer by setting the code-name to LOWCODE. However, he needs to explicitly do so. Otherwise the memory below the hires screen is totally wasted.
Trivia: Allowing to do this hires screen buffer "covering" was the very reason to change tgi_init() to not clear the hires screen anymore.
The change allows cc65 to be compiled on 64-bit Windows, without getting warnings. That OS is actually 32 bits with 64-bit pointers. Its pointers are "long long" instead of "long". The change uses type-names that are configured for the actual pointer width.
