The Vic20 does not have kernal table entries for the following functions.
;-----------------------------------------------------------------------------
; Functions which are not in the kernal jump table for VIC-20 but are for C64
CINT := $E518
IOINIT := $FDF9
RAMTAS := $FD8D
All other kernal entries are the same as the C64, however, without this change, the startup code fails.
Without this change the vic20.lib builds incorrectly.
It prevents the statement's Assembly code from being optimized (e.g., moved or removed). Optimization is disabled for that statement's entire function (other functions aren't affected).
_sys() is supposed to be (primarily) intended to call ROM routines. Leveraging the "file overlay" mechanism of the cc65 build system allows to provide a Apple II specific _sys() implementation that temporarily switches in the ROM.
- All segments but CODE are optional and CODE is R/W. Both together allow to "just" write code/data without ever explicitly using a segment.
- Symbols are defined for the BSS. This allows to use/implement zerobss.
- The ZP memory area isn't artificially limited.
In normal situations it isn't too useful to define symbols for optional segments as those symbols can't be presumed to be always present.
I in fact suspect that most currently present combinations of 'define' and 'optional' aren't useful - apart form the overlay configurations of course.
Make the same changes to the Apple II that were done with 0ee9b2e446 to the C64.
Notes:
- The startup code deliberately doesn't make use of symbols defined for the LC segment as that segment is optional.
- The <...>-asm.cfg configs move the segment BSS to an own memory area BSS although this doesn't seem necessary. However the benefit is that the size of the memeory area MAIN is identical to the number of bytes loaded from disk into RAM. To keep this an invariant for all Apple II configs allows to simplify the EXEHDR to just refer to the symbols defined for MAIN.
The constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the INIT segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized.
The CBMx10 targets don't use the INIT segment in the startup code. So it may turn out to be not necessary at all for certain programs.
The CBMx10 targets don't need symbols for the ONCE segment. Likely their definition was a C&P error in the first place.
The main chunk load header references __BSS_LOAD__ so BSS must be the first bss type segment. Subsequent changes will move ONCE to share its address with the BSS. Then it'll be necessary to load INIT from disk. Therefore we do it right now.
The BSS segment and the ONCE segment share the same start address. So they need to be placed in two different memory areas.
So far BSS was placed in the MAIN memory area and ONCE was placed in an additional memory area. Both memory areas were written to the output file. They just "happened" to be loadable and runnable at a stretch.
Now ONCE is placed in the MAIN memory area and BSS is placed in an additional memory area. Only MAIN is written to the output file. It becomes more obvious that BSS is "just" defined to share memory with ONCE.
