Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
for those who do not participate discord.
there are tremendous changes in SDCC made recent couple of weeks.
1. first of all, sdldgb linker and makebin utility are put into a working state. all __banked stuff is working from the box, there is no need for link-gbz80 anymore.
1.1. a new method of calling banked functions is introduced, which passes far pointer in E:HL, that results in more efficient trampoline functions and increase performance.
1.2. makebin has some new commandline arguments for gb
2. sdcc optimizer tries to allocate variables into registers with more enthusiasm. that results into big gain to the code performance. here is a comparison i made for genesis game from 0x7f:
2.2. thare are also much better rules for peephole optimizer, as built in, also third party: https://github.com/basxto/gbz80-ph
3. RGBDS mappings are fixed. you may use RGBDS assembler and linker https://rednex.github.io/rgbds/ as a backend for SDCC compiler. i even made a simple proto-library https://github.com/untoxa/RGBDK.git
all those improvements are already avaliable in revision #11777 or higher of SDCC, snapshot may be downloaded here: http://sdcc.sourceforge.net/snap.php
also:
4. in future releases __z88dk_fastcall calling convention might be allowed for gb target - that give some extra gain for single-parameter functions, because that parameter is passed in registers.
all that improvements became possible with the help of SDCC team: Philipp Klaus Krause, Sebastian Riedel, Sergey Belyashov; we we are looking forward for the new features.
unfortunately, current version of GBDK-2020 became unusable. those enhancements triggered usage of XL3 object file format which is not compatible with the old link-gbz80 linker.
but if you don't use lcc, then you have an ability to compile your sources directly by calling sdcc, sdasgb, sdldgb and makebin. you may also use a pre-compiled version of gbdk-2020 library, sdldgb is backward-compatible with older object files.
also you might need a new trampoline function, here it is: ___sdcc_bcall_ehl.s
.include "global.s" .area _BASE ___sdcc_bcall_ehl:: ; Performs a long call. ldh a,(__current_bank) push af ; Push the current bank onto the stack ld a, e ldh (__current_bank),a ld (.MBC1_ROM_PAGE),a ; Perform the switch rst 0x20 pop af ; Pop the old bank ld (.MBC1_ROM_PAGE),a ldh (__current_bank),a ret
Last edited by toxa (2020-07-28 16:17:41)
Offline
Thanks for all the work you've been putting in on this! It's great to see the tools and gbdk improving after it's long lull. It'll be a little sad to see less grumbling about the bugginess of GBDK.
I'm looking forward to eventually migrating eventually.
Related- I came across news that z88dk added gameboy support this year. I've posted details in a separate thread.
https://gbdev.gg8.se/forums/viewtopic.php?pid=4398
Last edited by bbbbbr (2020-07-27 13:34:36)
Offline
I removed info about AR library format from the original post, because i was wrong, that is not REQUIRED. this is optional, old text file format is still supported. if you want to make a single archive from multiple object files, you should use sdar utility:
sdar q gb.lib <all files from an old gb.lib text file>
sdar q gbz80.lib <all files from an old gbz80.lib text file>
then you may delete old object files except crt0.o, if you wish.
Offline
here is an example of bat-file for building some "test3.c" file into gb rom with the native sdcc toolchain:
@rem @echo off @set PROJ=test3 @set GBDK=..\..\gbdk @set GBDKLIB=.\lib @set OBJ=build @set CFLAGS=-mgbz80 --no-std-crt0 -I %GBDK%\include -I %GBDK%\include\asm -I src\include -c @set CFLAGS=%CFLAGS% --max-allocs-per-node 10000 @rem @set CFLAGS=%CFLAGS% --opt-code-speed @rem @set CFLAGS=%CFLAGS% --opt-code-size @set LNAMES=-g .OAM=0xC000 -g .STACK=0xE000 -g .refresh_OAM=0xFF80 -b _DATA=0xc0a0 -b _CODE=0x0200 @set LFLAGS=-n -m -w -j -i -k %GBDKLIB%\gbz80\ -l gbz80.lib -k %GBDKLIB%\gb\ -l gb.lib %LNAMES% @set LFILES=%GBDKLIB%\gb\crt0.o @set BINFLAGS=-yt 2 -yo 4 -ya 4 @set ASMFLAGS=-plosgff -I%GBDKLIB% @echo Cleanup... @if exist %OBJ% rd /s/q %OBJ% @if exist %PROJ%.gb del %PROJ%.gb @if exist %PROJ%.sym del %PROJ%.map @if exist %PROJ%.sym del %PROJ%.ihx @if exist %PROJ%.map del %PROJ%.noi @if not exist %OBJ% mkdir %OBJ% @echo COMPILING WITH SDCC4... sdcc %CFLAGS% %PROJ%.c -o %OBJ%\%PROJ%.rel @echo LINKING... sdldgb %LFLAGS% %PROJ%.ihx %LFILES% %OBJ%\%PROJ%.rel @echo MAKING BIN... makebin -Z %BINFLAGS% %PROJ%.ihx %PROJ%.gb @echo DONE!
Last edited by toxa (2020-07-28 16:28:57)
Offline
toxa wrote:
3. RGBDS mappings are fixed. you may use RGBDS assembler and linker https://rednex.github.io/rgbds/ as a backend for SDCC compiler. i even made a simple proto-library https://github.com/untoxa/RGBDK.git
This is really really interesting. This means that now we don't need to use the other crappy assembler. RGBDS is so much better.
Offline
AntonioND wrote:
This is really really interesting. This means that now we don't need to use the other crappy assembler. RGBDS is so much better.
i don't see much difference: rgbds is also odd and crappy, but only in some other way. but yes, you have an option now to choose from the sorts of crap.
you may help me with RGBDK, if you wish. i wanted to make some mix of C and asm, some kind of assembler-centric kit, or at least where asm and C are equal. you write some random C code, some random asm code, put that together with resources into directories and that is all gets build and work together.
i need some help with makefiles and open to other ideas, welcome. i also need help with some advanced macros stuff. RGBDK repo: https://github.com/untoxa/RGBDK
Last edited by toxa (2020-08-05 17:06:31)
Offline
RGBDS is much more flexible in so many ways. I wouldn't bother to support my GBT player in that old GBDK assembler, but if they switch to RGBDS I will definitely be more interested in supporting it. With RGBDS I could add support for arbitrarily long songs because the linker just puts each segment in a different bank and then I can get the references to each bank with assembler functions. I couldn't do that with GBDK, for example.
Offline
we can make similar references in C. look into far_ptr example.
yes, there is no way to determine the bank where the object is landed (for now), but you have to specify that with #pragma bank N, those banks are not random, anyway, so why not use that N as a constant for making pointers onto that blocks.
Last edited by toxa (2020-08-07 11:53:55)
Offline