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.
The Apple II hires screen buffer is located at $2000 (and can't be moved). The usual way to get along with this is to load the cc65 program above the hires screen buffer at $4000. However, that means that it becomes difficult to make good use of the memory below the hires screen buffer. The simplest approach is to add that memory to the heap. But there are programs containing just lots of code and not much data. One could think of moving the code to the area below the hires screen after loading (like it is done with the code for the language card). But if the program is really large (and already contains code to be moved to the language card) it won't just fit into memory in the first place.
The alternative is to load the program at the usual $803 and have it "cover" the hires screen buffer. Of course the part of the program that actually "covers" the hires screen buffer mustn't contain anything necessary for the program. The downside of this approach is that the program file on disk contains 8kB that can't be used by the program. But instead of just containing zeros the program can as well contain a hires screen picture that can be displayed right after startup.
Now the user can have code loaded below the hires screen buffer by setting the code-name to LOWCODE. However, he needs to explicitly do so. Otherwise the memory below the hires screen is totally wasted.
Trivia: Allowing to do this hires screen buffer "covering" was the very reason to change tgi_init() to not clear the hires screen anymore.
This change includes some cleanups, removal of mainargs.s (game console
programs never have arguments), and a workaround for a problem I'm seeing.
The problem is that sometimes (in fact, more often than not) the clrscr()
call in testcode/lib/joy-test.c writes some garbage chars on the screen (most
often a "P"). Could be my hardware (I haven't seen it on MAME), but to
me the root cause is still unknown.
The configuration file and runtime (crt0.s) provided for the default NES
ROM layout (2x16k PRG, 8k CHR) incorrectly added interrupts (IRQ1, IRQ2,
TIMERIRQ) which are not supported by the NES hardware. For example, see
the NESdev wiki, which makes no reference to these interrupts.
https://wiki.nesdev.com/w/index.php/CPU_memory_map
The VECTORS region was also incorrectly set to 0xFFF6, which would have
left the 0xFFF4 normally unspecified. This did not result in any error,
however, since cc65 simply placed ROMV directly after ROM0 regardless of
start address.
(This layout may be due to a copy-and-paste from the PC-Engine
configuration, whose interrupt registers start at 0xFFF6, begins with
the three interrupts listed above, followed by NMI and START, and does
not end with a final IRQ interrupt.)
Despite the absence of any actual error, since START is still placed at
0xFFFC, this patch removes the nonexistent interrupts and also correctly
aligns the ROM0 and ROMV regions. It also has the (admittedly very
minor) benefit of freeing up 6 additional bytes for ROM0.
- 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.
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.
