The driver requires a special linker configuration: "vic20-tgi.cfg".
The VIC-20 computer needs at least 8K of expansion RAM!
"tgidemo.c" needed to be adjusted because the VIC-20's vertical (y) range is greater than its horizontal (x) range -- the opposite of most other platforms. Also, the circle demo would jam on the VIC-20.
Cleared the screen at the beginning of each demo instead of at the end. Setting the colors before clearing makes it more reliable and consistent across platforms.
--print-target-path may return a path with (escaped) spaces. We'll use that path with $(wildcard ...), that's fine. But then we use the outcome with $(foreach ...) and there things fail badly and there's nothing to do about it.
Therefore we a) try to avoid --print-target-path in the first place and b) explicitly bail out if we end up with spaces.
Although the primary target OS for the Apple II for sure isn't DOS 3.3 but ProDOS 8 the Apple II binary files contained a DOS 3.3 4-byte header. Recently I was made aware of the AppleSingle file format. That format is a much better way to transport Apple II meta data from the cc65 toolchain to the ProDOS 8 file system. Therefore I asked AppleCommander to support the AppleSingle file format. Now that there's an AppleCommander BETA with AppleSingle support it's the right time for this change.
I bumped version to 2.17 because of this from the perspective of Apple II users of course incompatible change.
mouse-test.c can be use to test all available mouse drivers for a given target.
Currently supported targets are Atari, C64, and C128.
To avoid confusion, rename samples/mousetest.c to mousedemo.c.
<conio.h> includes target-specific headers; so, we didn't bother to include <cbm.h> where it is needed. But, '#include <conio.h>' was removed from some files; so now, we must include <cbm.h> explicitly.
The 'all' target deliberately doesn't build the doc nor the samples. But that doesn't mean that the Makefiles in the 'doc' and 'samples' directories must default to the (empty) 'all' target.
Just a few of the many reasons why shell for-loops have no place in (GNUmake) Makefiles:
* They don't conform to https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html
* They break Windows builds for sure
* They don't fit to make's approach of working with sets
* They break make parallelism
