#77 patches to support gb/z80 bank switching
Attached please find the patches to the code I had to make in order to make bank switching work for the Gameboy/GameboyColor.
a) I didn't change the functionality as it is in the compiler. It works as described in the manual - to the extent it is described at all. That is, I did the minimum changes necessary to make it work.
b) I also removed the start/end extra global symbols which didn't add anything but clutter to the map listing in my opinion.
c) I've used the compiler - with the attached patches on a small test program for the Gameboy as well as a large "real world" program. This program has been run on the VGB simulator and downloaded into a cartridge which supports bank switching. I quite confident that it works as one would hope.
d) Personally, I think that bank switching support could be improved a lot with different bank syntax that would permit bank switching to be resolved at compile time. When I first built my "real" program it was very slow due to bank switching in interrupts (a facility I HAD to have). I was able to resolve it by modest reorganization of my code modules. But with a different system this would not have been necessary. As currently implemented - bank switch calls are made when code is in different modules even though the code is in the same bank.
e) Needs to be added to the documentation:
"#pragma bank <bank #>" is used to specify that all code and const data in the current module will be placed in the indicated memory bank."
f) The usage of bank switching requires support from the runtime library. Currently, this support is only available in the GameboyDevelopmentKit gbdk. Note that i have my own moderatly modified version of the gbdk which supports this. I would be willing to upload this somewhere - but I'm not sure where to do it.
Robert Ramey
Patches to correct bank switching on z80/gbz80
Logged In: YES
user_id=888171
Originator: NO
Robert,
Can you please describe the modifications you made to the runtime library or gbdk? Or better upload them here attached to this patch?
This patch looks ok and I will apply it with only a slight modification to check for target z80/gbz80 in SDCCglue.c.
Maarten
Logged In: YES
user_id=888171
Originator: NO
Robert,
I'm still waiting for your modifications to the runtime library.
Also I have trouble reading/applying the diffs on some files. Can you please generate a unified patch/diff with at least 3 lines of context (diff -u)?
Maarten
latest copy of crt0.s which supports bank switching
Logged In: YES
user_id=396141
Originator: YES
File Added: crt0.s
Logged In: YES
user_id=396141
Originator: YES
File Added: global.s
Latest changes to support bank switching on gameboy
permits divide to be used in interrupt driven code
Logged In: YES
user_id=396141
Originator: YES
I've uploaded two files crt0.s and global.s from my system. These files are modifications of those found in the gbdk 2.95. I included the whole file rather than the diffs as I wasn't sure what to diff them against. The files aren't very long in any case.
This change implements bank switching and permits "nested" disable/enable interrupt instructions. Lack of this caused problems with interrupt driven code.
I've also included a modified version of div.s I don't know if I modified the one with the SDCC package or the one from the gbdk - the might even be the same. This patch solves a problem where by if one invokes a division from an interrupt handler and also from the main line code - results are unpredicatble. This was due to the usage of static varible in the divide routine. This static variable has been elimated in favor a stack based one. The results are not correct but the divide code is a little bit longer. Note that the z80 could also benefit from a modification such as this.
I have one more file which I could upload if you wish. I haven't tested it.
File Added: div.s
Logged In: YES
user_id=888171
Originator: NO
Applied modified div.s in SDCC 2.8.1 #5187.
That's what i'm doing (have to do) with far_fixer: https://github.com/untoxa/sdcc4_farcalls_example Philipp, may be you merge that at last? Thank you.
Why such useful patch is still not merged after 7 years?
After all this time and with Philipp having done most Z80 related development, I have no idea what to patch where anymore. I would unassign myself if I could.
Philipp, can you have a look and apply or close as you see appropriate?
the patch itself! :) sdcc still generates:
instead of:
and
somewhere above
Tony, I want to implement banking support for Z80 too. Let's go...
First, my suggestion is to use code:
So common implementation of banked_call will fit one RST handler if banked_jump RST too (idea of Maarten Brock):
Second, I need updated patches for recent SDCC code tree.
Last edit: Sergey Belyashov 2020-07-15
if you patch the z80 target that automatically patch the gbz80 too unless you ifdef against that. i guess that SDCC for z80 also generates _CODE_N and _DATA_N areas, all you need to do is to generate symbols containing that N, like: MyBankedProcBank = N and make SDCC emit .dw MyBankedProcBank instead .dw 0. that is a universal solution for all z80 family.
you may have any implementation of the trampoline functions themselves (my gbz80 variant for GBDK-2020 tracks the active bank number, for example)
the problem that b_some_bank2_proc is not emitted.
that variant is not very good, because you allocate HL and E, that is too much. gbz80 has only 6 registers. :) you might at least do A:HL instead of E:HL, so DE might be used as a pointer for outside code. that approach with "call banked_call, .dw bank_proc, .dw bank_proc_bank" is more or less nice. anyway, the generation of bank_proc_bank symbol is a key feature for universal solution.
A:HL is bad idea, because you reserve both accumulators. So any ALU or I/O operation will require save them. I think, all can be done in mappings.i...
that's common for gbz80: https://github.com/pret/pokecrystal/blob/master/home/farcall.asm
"ldh" is actually an alias for "out". i don't see why that should be a problem.
if you look through the SDCC code generation, you see, that preserving A is quite useless, DE is more important.
As you know, SDCC assume that after the call all registers are clobbered.
As you may see, function is shorter and faster.
who cares about trampoline function implementation, when the bank number is not generated? that's all a useless discussion.
no. if you declare a function with __preserves() keyword, then it may allocate DE for something useful withput push/pop which may be more expensive than juggling A.
there is also a "banked stuff" related issue: https://sourceforge.net/p/sdcc/bugs/3004/ that seem to be a hopeless case too. i really don't understand the logic how maintainers decide what issues to fix. ;)
Last edit: Tony Pavlov 2020-07-15