At some point we'll be doing automatic linking of large programs, perhaps with some algorithm that can distribute code and data to minimize banking and make intelligent decisions about what code should be duplicated (or can be duplicated) to avoid banking. But the tools for manual banking have to be solid first.
The handling is quite good in z88dk now but there are still a couple of issues that need solving, one of the primary ones being we don't currently have a scalable method to define memory maps. The library code is separated into modules (heap allocation, block allocation, obstack, abstract data types, stdio, string, math, etc) and placed in independent sections so that the user can take control of placement of library code in memory if he wants it. That means there is a proliferation of SECTIONs in the memory map (SECTION being z80asm's equivalent of .AREA in sdasm) so making a completely custom memory map involves copying all these sections into a new memory map which can be intimidating (even if it's easy) and error-prone since new sections may appear for new modules added to the library. The proposed solution we have is simple - the memory map should accept wild-carded section names. So you can say put all "code_*" sections here unless there is a more specific match for the section name.
This also affects 3rd party library code. There is a 3rd party library code manager in z88dk ("z88dk-lib") that can install and uninstall 3rd party libraries. These libraries are compiled into sections and code from the library is placed in memory according to the user's memory map which says where those sections go. Ideally the 3rd party library names its sections uniquely as in "code_spritelib_XXXX" where XXX may be a signature, author name, whatever. Then the user can add that section to his memory map but right now this might entail making a complete memory map from scratch (it depends if the sections can be appended to the memory map rather than requiring insertion). 3rd party libraries are only recently being discovered by some people and what they've done is placed their code and data in standard user sections that are already in the "main binary" of the memory map. "code_user", "data_user", etc. But this means the code can't be moved into other memory banks. The current solution is to use another of z88dk's tools zobjcopy
to change the section assignment of the 3rd party code to something else in the user's memory map, like another memory bank.
Anyway before the automatic placement is attempted, these other things should be solved. Then with automatic placement a couple of more things need to be defined like defining islands in memory that can't be placed into, and so on.
But for code that takes over the machine, I personally prefer having full control without automatic banking as it is now.
NextOS introduces another complication in that it has a page allocator built in. This means programs can be loaded and left running when they exit so that TSRs, drivers, etc can co-exist with the system and basic which is the primary interface to the system. To make use of this, the loader has to allocate pages the program gets loaded into and needs for workspace and it must write those pages into a table of logical to physical page mappings inside the loaded program. The loaded program must then use this table when it does any banking. This is within z88dk's capability now so we'll be doing that one too.
BTW, relevant to fuzix is how banked relocatable code can work. SymbOS does this for the z80 :- it generates multiple banks of code into a single binary ORGed at 0 that is segmented with pointers to the start of each segment. Then the linker can supply relocation data for the org 0 monolithic binary. As the SymbOS loader patches the binary and moves the pieces into available ram, it looks at the original (org 0) address, finds out what segment the patch applies to and adds a different offset depending on where that segment gets placed in ram. Anyway, in case you hadn't seen it. There are bugs in SymbOS's relocation that will cause it to fail but those bugs go away if everyone agrees that relocation only happens in steps of 256 bytes.