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 :-((
Originally I used the usual variables (like $(CC) and $(CFLAGS) ) but after
all this doesn't make sense as any predefined values and/or user defined
settings can only be wrong.
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'.
However now I understand that CBM GEOS does _not_ use PETSCII so the CBM character specification table doesn't make sense at all. After all this is very plausible because GEOS wants to enable the user to share his files across GEOS variants - so we can share the character specification table too.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5527 b7a2c559-68d2-44c3-8de9-860c34a00d81
As the disk driver jumptable entries don't seem to be published otherwise I didn't delete the definitions but moved the '_' to the end marking them as "secondary" to the ones in the main jumptable.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5506 b7a2c559-68d2-44c3-8de9-860c34a00d81
- According to the "Hitchhiker's Guide To GEOS" GetSerialNumber returns a string on Apple GEOS (in contrast to a number on CBM GEOS).
Given both facts and that the API is presumably not important at all it seems reasonable to just go without it on Apple GEOS.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5503 b7a2c559-68d2-44c3-8de9-860c34a00d81
Now the whole GEOSLib is built in a single make instance running in 'libsrc/geos-cbm' - which is just what the cc65 library build system can handle. The 'libsrc/geos-cbm' sub-directories still contain Makefiles. However those files only define the set of object files to create from their sub-directory and get included into the 'libsrc/geos-cbm' Makefile.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5429 b7a2c559-68d2-44c3-8de9-860c34a00d81
