The target util convert.system is to be used in conjunction with GEOS on the Apple II but has to be built as an "ordinary" Apple II program. The way the cc65 library build system is designed there's no way to define dependencies between targets. The solution used so far was to explicitly trigger a build of the target 'apple2enh' from the target 'geos-apple'. However, that approach tends to break parallel builds which may be in the middle of building 'appple2enh' at the time it is triggered by 'geos-apple'.
There might be ways to get this fixed - but the the cc65 library build systrem is already (more than) complex enough, so I really don't want to add anything special to it.
On the other hand there are easier ways (outside the scope of cc65) to archive what convert.system does so I don't presume convert.system to be actually used - it's more a reference type of thing.
Putting all facts together the decision was easy: Just move convert.system from the target it is used with to the target(s) it is built with.
Instead of `val` right (left) shifts, we can also do `9 - val` left (right)
rotates and a mask. This saves 3 bytes and 8 cycles for `val == 7` and
1 byte and 4 cycles for `val == 6`.
If lhs and rhs are either both signed char or both unsigned char,
return flags for that type instead of (unsigned) int. The flags
are used only for codegen. Currently, this does nothing, since
codegen treats chars as ints unless CF_FORCECHAR is set, but it
allows more efficient char x char -> int codegen to be added in
the future.
Only the low bytes are compared. Originally, signed 16-bit compares were optimized into signed 8-bit compares. But, the sign bits are in the high bytes; and, they're equal. Therefore, the low bytes always must be compared as unsigned numbers.
Fixes#1348.
Certain scenarios (e.g. not running any Applesoft program at all since booting DOS 3.3) can make DOS 3.3 consider cc65 device input (e.g. getchar()) that reads a CR interpreting the command in the keyboard buffer. Setting the hibyte of the Applesoft currently executed line number to some value <> $FF (beside setting the input prompt to some value <> ']') makes DOS 3.3 understand that we're not in intermediate mode and that therefore I/O not preceded with ctrl-d mustn't be fiddled with (see DOS 3.3 routine at $A65E).
