So far the INIT segment was run from the later heap+stack. Now the INIT segment is run from the later BSS. The background is that so far the INIT segment was pretty small (from $80 to $180 bytes). But upcoming changes will increase the INIT segment in certain scenarios up to ~ $1000 bytes. So programs with very limited heap+stack might just not been able to move the INIT segment to its run location. But moving the INIT segment to the later BSS allows it to occupy the later BSS+heap+stack.
In order to allow that the constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the new INITBSS 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.
Up to now static drivers were created via co65 from dynamic drivers. However there was an issue with that approach:
The dynamic drivers are "o65 simple files" which obligates that they start with the 'code' segment. However dynamic drivers need to start with the module header - which is written to. For dynamic drivers this isn't more than a conceptual issue because they are always contain a 'data' segment and may therefore only be loaded into writable memory.
However when dynamic drivers are converted to static drivers using co65 then that issue becomes a real problem as then the 'code' segment may end up in non-writable memory - and thus writing to the module header fails.
Instead of changing the way dynamic drivers work I opted to rather make static driver creation totally independent from dynamic drivers. This allows to place the module header in the 'data' segment (see 'module.mac').
This change was suppsed to fix the issue that the former JUMPTABLE is merked as 'ro' while it is actually written to in several scenarios. When drivers are converted using co65 and then compiled into ROMs the JUMPTABLE isn't copied to RAM and therefore the write operations in question fail.
However unfortunately I didn't succeed in changing that :-( Just setting the former JUMPTABLE to 'rw' broke the drivers. So I placed the DATA segment directly after the former JUMPTABLE segment. This made the drivers converted with co65 work again - obviously after changing libsrc/Makefile:235 from '--code-label' to '--data-label'. But the actual dynamic drivers still didn't work as the former JUMPTABLE wasn't placed as the beginning of the loaded file anymore. That effect could be changed by exchanging src/ld65/o65.c:1391 with src/ld65/o65.c:1394 but doing so broke the drivers again :-((
Occasionally dynamically drivers suffer from not being to refer to
content in the C library. Therefore I added a mechanism to allow
a C library for a certian target to define a symbol that will be
handed over to dynamic drivers for that target. Then the drivers
can use their refernce to that symbol to access content in the C
library.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
machines, the program runs in a separate 64K bank, and zeropage variables need
to be copied from the system bank into the execution bank to read by a simple
load operation. The change is currently untested!
git-svn-id: svn://svn.cc65.org/cc65/trunk@4597 b7a2c559-68d2-44c3-8de9-860c34a00d81
named EXEHDR.
* Renamed BASICHDR to EXEHDR for the PET-II machines.
* Moved the call to CHRCH in front of the code that saves the zero page, since
open files are sometimes remembered in the zero page, so we need to close
them before we grab a copy.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4507 b7a2c559-68d2-44c3-8de9-860c34a00d81
in the distribution.
Added --forget-inc-paths to the command line of the assembler in the
Makefiles, because the assembler does now have builtin paths and will find
include files from an installation first.
Hopefully fixed any problems that arose from the two changes.
git-svn-id: svn://svn.cc65.org/cc65/trunk@4223 b7a2c559-68d2-44c3-8de9-860c34a00d81
main() is encountered. Define this symbol in the startup code. This will
automatically force linking of the startup code which can then reside inside
the standard library as any other object file.
git-svn-id: svn://svn.cc65.org/cc65/trunk@3988 b7a2c559-68d2-44c3-8de9-860c34a00d81
routine reads the TOD clock of CIA1 on the C64 and C128. Since systime was a
dummy routine common for all CBMs before, this change adds an individual dummy
routine for all other CBM systems. CBM510/610 do also have a TOD clock, so a
similar function as in the C64 could be used ...
git-svn-id: svn://svn.cc65.org/cc65/trunk@3974 b7a2c559-68d2-44c3-8de9-860c34a00d81
before calling initlib because initlib calls contructors and may install
drivers, which enable hardware interrupts. Similar for donelib.
See also R3897 and R3951 where this change was done for other platforms.
git-svn-id: svn://svn.cc65.org/cc65/trunk@3954 b7a2c559-68d2-44c3-8de9-860c34a00d81
in the system bank. For one this performs better (several %), second it
allows to handle the function keys in conformance with other platforms.
Without the custom keyboard routine, we would have to apply some more
magic to the function keys to make them work as with other cc65 targets.
git-svn-id: svn://svn.cc65.org/cc65/trunk@2811 b7a2c559-68d2-44c3-8de9-860c34a00d81
Use wrappers to call the kernal in bank 15 instead of implementing kernal
functionality within the cc65 libs (eats performance but is much smaller and
simpler).
Improved startup/shutdown code allows a return to the system bank without
calling the BASIC cold start vector.
git-svn-id: svn://svn.cc65.org/cc65/trunk@2793 b7a2c559-68d2-44c3-8de9-860c34a00d81
