The final part of exec() called 'excexit' and only then restored the
stack pointer to its value at program entry. 'excexit' does all
cleanup (the same as '_exit()'), which means that on the atarixl
target the ROM is banked in again. On big programs the 'SP_save'
variable might reside at a high memory address which is no longer
accessible after the ROM has been banked in.
The change just moves the restoration of the stack pointer before
the call to 'excexit'.
Another change lets exec.s compile if UCASE_FILENAME is not defined.
And some other small cleanups, also in open.s.
- Adds new ENOEXEC error code, also used by Apple2 targets.
- Maximum command line length is 40, incl. program name. This is
an XDOS restriction.
- testcode/lib/tinyshell.c has been extended to be able to run
programs.
* libsrc/atari/ucase_fn.s: Fix handling if input parameter 'tmp2' is 0.
* libsrc/atari/open.s: Set 'tmp2' parameter for 'ucase_fn' if DEFAULT_DEVICE
is not defined.
About all CONIO functions offering a <...>xy variant call
popa
_gotoxy
By providing an internal gotoxy variant that starts with a popa all those CONIO function can be shortened by 3 bytes. As soon as program calls more than one CONIO function this means an overall code size reduction.
If cc65 is installed and used as designed there's no need whatsoever for CC65_HOME (both on *IX and Windows) from the perspective of the cc65 binaries. If the user however has to access files from the 'target' directory thenhe ends up with some assumption on the cc65 installation path nevertheless :-(
In order to avoid this I added the --print-target-path option. It "exports" the logic used by the cc65 binaries to locate their files to the user thus allowing him to leverage the same logic to locate the target files in his build scripts / Makefiles.
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.
No cc65 tool creates *~ files so we don't cleanup *~ files. If some other tool (like an editor) creates *~ files it's up to the user - and only him - to decide when those files are to be deleted !
