- Adjusted the 'tutorial' Makefile to actually work as expected.
Note: The 'disasm' and 'geos' Makefiles don't seem to work so they are not called as of now.
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.
--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.
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
The samples Makefile serves educational purposes. From that perspective it's counterproductive to hide the actual build commands. Apart fom that it becomes visible if an installed cc65 is used to build the samples.
Now that the clean goal of the samples Makefile is part of the global clean goal it should work on Windows!
BTW: Ideally the whole samples Makefile should work on Windows ;-))
Other targets have disks too and if at some point some one is interested enough to add support for disk creation for other targets too then 'disk' is no good goal name for a C64 disk.
