* Added ONCE and INIT segments to the Assembly configuration.
* Made more segments optional in the standard and the banked configurations. That will make them a little easier to use with Assembly-source programs.
Requiring the HGR segment makes the configs a little less flexible, but for the intended use case the HGR segment actually is necessary. And as we learned now, making the HGR segment obligatory helps users to not shoot themselves in the foot.
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.
load and run address now configured from header
fix error codes not to conflict with test
fix test/misc/endless.c which is supposed to fail if an endless loop does not occur
Extendend memory is mapped over the main memory in the 0x4000..0x7FFF
area. Many DOSes disable interrupts while extended memory is banked in,
but not all (e.g. SpartaDOS-X).
This change modifies the initial interrupt handler to map in main memory
before chaining to the "worker" handlers.
Since the initial interrupt handler uses a data segment to store the
trampoline to chain to the original handler, introduce a new "LOWBSS"
segment to hold this trampoline. Otherwise the trampoline may end up
inside the 0x4000..0x7FFF area.
Add a link time warning if "LOWCODE" segment lays within the extended
memory window.
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.
The unexpanded Creativision has only $206 bytes of RAM available to cc65 programs. So it's a bad idea(tm) to reserve $180 bytes for the software stack. $40 bytes seems a much better default (aka guess).
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.
