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.
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 name RAM doesn't make much sense in general for a memeory area because i.e. the zero page is for sure RAM but is not part of the memory area named RAM.
For disk based targets it makes sense to put the disk file more into focus and here MAIN means the main part of the file - in contrast to some header.
Only for ROM based targets the name RAM is kept as it makes sense to focus on the difference between RAM and ROM.
The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name.
Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
Moving __cwd from BSS into INITBSS does of course ;-) not only impact the CBM targets but all targets with disk I/O support.
Note: Code using `__cwd-1` may trigger an ld65 range error because __cwd may end up at the very begining of a segment. As far as I see this is an ld65 bug which I'm not try to fix - at least here.
This reduces the potential to flicker, but creates two separate
memory areas in the high memory.
For applications which require a large continuous memory space in
high memory, atarixl-largehimem.cfg is provided. With high IRQ
activity or DL interrupt there might be flicker.
