Maybe an idea to make sure one reads everything in the thread first? Ok, I'm investigating "s_vgm" now 
Ok, tried to check out s_vgm, but didn't get the total overview. Could you explain how you would call another function in another segment in page 1 while the PC currently is inside page 1?
I think that MSXgl or other libraries cannot help. If we want the compiler and the linker deal with page numbers and page swapping we have to understand the new features of SDCC v4.1.14.
http://sdcc.sourceforge.net/doc/sdccman.pdf
From what i read you can use the __banked keyword in the declarations of functions that need a page swap.
4.3.9 Z80 banked calls
Banked calls are supported via __banked. Banked calls are done via a trampoline (__sdcc_bcall if --legacy-banking us specified, __sdcc_bcall_abc for z88dk_fastcall, __sdcc_bcall_ehl for other calls). Default trampolines are provided in the library. The default trampolines calls user supplied helper functions set_bank and get_bank that set the current bank to the value in register a, or return the current bank in register a.
For banked functions, the calling convention is slightly different: the stack is always cleared up by the caller.
Unless __z88dk_fastcall is used, all parameters are passed on the stack.
The user has to provide the functions set_bank and get_bank, according to the mapper you have. Bank pages can be defined by a #pragma directive of by --codeseg commandline parameter
Normally all functions you write end up in the segment CSEG. If you want a function explicitly to reside in the common area put it in segment HOME. This applies for instance to interrupt service routines as they should not be banked.
Functions that need to be in a switched bank must be put in a named segment. The name can be mostly anything up to eight characters (e.g. BANK1). To do this you either use --codeseg BANK1 (See 3.3.4) on the command line when compiling or #pragma codeseg BANK1 (See 3.16) at the top of the C source file. The segment name always applies to the whole source file and generated object so functions for different banks need to be defined in different source files.
When linking your objects you need to tell the linker where to put your segments. To do this you use the following command line option to SDCC: -Wl-b BANK1=0x18000 (See 3.3.5). This sets the virtual start address of this segment. It sets the banknumber to 0x01 and maps the bank to 0x8000 and up. The linker will not check for overflows, again this is your responsibility
Hello,
I have been using banked calls for quite some time in my engine even before it was supported in sdcc 4.1.12.
see : https://github.com/retrodeluxe/sdcc-msx
and : https://github.com/retrodeluxe/rlengine-msx
Also samsaga looked into how to use it 4.1.12 and made some sample code:
https://msx.org/forum/msx-talk/development/at-least-i-know-h...
Is not as straightforward as it seems, specially when you get into doing nested calls (calling a banked function from another banked function), but once you understand it, it works quite well and the performance penalty is acceptable for non speed-critical functions.
The main shortcoming is that the split of code and data into pages of a specific size needs to be done by hand.
Good to know! Thanks!
Thanks guys! Very interesting!
@Bengalack Here is how I handle mapped ROM in MSXgl.
First, the initial 32 KB are compiled/linked as a normal 32 KB plain ROM.
Then, for each extra segment of the ROM (number depend on the segment size and ROM total size), the Build Tool search for file with a specific naming convention. For example ”project_s10_b3.c” for segment #10 to be use in bank #3 (A000h~BFFFh).
The Build Tool compile and link the segment to be used at the bank address, then add it to the binary.
Currently, the symbols of the segment are not accessible from the main program or from the other segments. However, within a segment, you can call other functions or directly access the data.
I planned to convert the symbols of the segments (the NoIce files) into a header file (.h) to make them accessible to the main program. They won't be typed (the symbols are just addresses) but at least it will make using the segment data easier.
I’ll check the SDCC __banked directive but I have a doubt about its usefulness while I prefer to handle bank switching manually.
To change the segment of one of the banks, just use the macro:
SET_BANK_SEGMENT(bankNum, segmentNum);
The macro automatically adapts to the type of mapper chosen during the build.
samsaga2 seems to be using the compiler features for banked functions.
All trampoline functions are here
https://github.com/samsaga2/sdcc_megarom/blob/master/src/meg...
@geijoenr
greetings for implemented a fork of SDCC where you have added the large model for z80 banked roms
I think that many optimisations have occurred since your fork. Why not contributing to the official SDCC development to add these features to the official compiler ?
greetings for implemented a fork of SDCC where you have added the large model for z80 banked roms
I think that many optimisations have occurred since your fork. Why not contributing to the official SDCC development to add these features to the official compiler ?
yeah, I don't know if those features can be merged. SDCC supports many targets; is easy to make changes for just one of them, but is difficult to ensure you are not breaking something in some other target. I can try to rebase my changes to 4.1.12 and post something in their forum to see what happens.
samsaga2 seems to be using the compiler features for banked functions.
All trampoline functions are here
https://github.com/samsaga2/sdcc_megarom/blob/master/src/megarom.s
Yes, I've looked at this in detail, but I'm really not convinced about the automatic bank switching on function calls.
A bank switch is a critical impact mechanism and I think it's important to keep these changes visible to the user.
However, I am very interested in the linker bank system to add segment in the final binary.
This will allow to use the data and function symbols of any segment in any other segment.
I will update my Build Tool to use this feature.