gbdk-2020 / gbdk-2020

An updated version of GBDK, C compiler, assembler, linker and set of libraries for the Nintendo Gameboy, Nintendo Entertainment System, Sega Master System, Sega Game Gear.

GBDK-2020

GBDK is a cross-platform development kit for sm83, z80 and 6502 based gaming consoles. It includes libraries, toolchain utilities and the SDCC C compiler suite.

Supported Consoles: (see docs)

• Nintendo Game Boy / Game Boy Color
• Analogue Pocket
• Sega Master System & Game Gear
• Mega Duck / Cougar Boy
• NES

Experimental consoles (not yet fully functional)

• MSXDOS

Current Release

Upgrading to a new version? Check the Migration notes. You can find older versions here.

For a full list of changes see the ChangeLog file or online Docs.

Build status

Docs

GBDK includes extensive documentation. A good place to begin is the Getting Started Section.

Check the Links and Third-Party Tools Section for a list of recommended emulators, graphics tools, music drivers and more.

For SDCC you can check its website and the manual

Usage

Most users will only need to download and unzip the latest release

Then go to the examples folder and build them (with compile.bat on Windows or running make). They are a good starting point.

The sources in this repo are only needed if you want to re-compile GBDK-2020 yourself instead of using the release binaries linked above.

Discord servers

• gbdk/zgb Discord - For help with using GBDK (and ZGB), discussion and development of gbdk-2020

• gbdev Discord - There is a #gbdk channel and also people with a lot of Game Boy development knowledge

• SMS Power! Discord - Additional SMS & Game Gear discussion and resources.

Forums

• The Game Boy Development Forum - A good place to search for Game Boy related answers.
• SMS Power! Forum - Additional SMS & Game Gear discussion and resources.

Current status

• Updated CRT and library that suits better for game development
• SDCC Versions
  • A custom build of SDCC is used with patches to support Sega GG/SMS and the Nintendo NES. See the github workflow for details of how to patch and build SDCC.
  • The default calling convention changed in SDCC 4.2. This is supported starting with GBDK-2020 4.1.0. Older versions of GBDK should use SDCC builds #12539 or older (see per-version GBDK notes).
• The compiler driver lcc supports the latest sdcc toolchain.

Origin

Over the years people have been complaining about all the GBDK issues caused by a very old version of SDCC (the compiler). This is a proper attempt of updating it while also keeping all the old functionality working, like support for banked code and data and so on.

The last version in the OLD repo is 2.96 although releases are available until 2.95-3. Version 2.96 is the starting point of this repo.

Build instructions

Unless you are interested on recompiling the sources for some reason (like fixing some bugs) you don't need to build GBDK

• Windows only: Download and install mingw
• Clone, download this repo or just get the source from the releases
• Download and install the PATCHED sdcc builds from the separate repo for that (https://github.com/gbdk-2020/gbdk-2020-sdcc).
• On Linux don't use package managers The latest release available won't work, you need to compile or download one of the nightlies
• Create SDCCDIR environment variable, that points into the folder, where you installed sdcc
• Open command prompt or a terminal, go to the root directory of the repo and run make

gbdk-2020's Issues

Linux build

I downloaded the source code of the 3.0 version to build it on linux (Ubuntu 19.10).
First I compiled sdcc-4.0.0 from source and defined SDCCDIR environment variable accordingly.
Had some issues:

First, in the as/ and link/ subdirectories, the makefiles have a reference to as-gbz80.exe and link-gbz80.exe in the strip phase, so compilation fails (linux executables don't have an extension)

Then after the instalation with make install, when trying to compile the examples, had some problems with the paths, for example:

> make
../../bin/lcc -Wa-l -Wl-m -Wl-j -c -o galaxy.o galaxy.c
../../bin/lcc: /opt/gbdk/bin/SDCC/bin/sdcpp: No such file or directory
make: *** [Makefile:26: galaxy.o] Error 1

That's because sdcpp is installed in /opt/gbdk/bin/sdcc-4.0.0/bin/sdcpp and not on .../SDCC/...
Creating a symlink there works.
Then some examples also fail, but most work.

Strange error with banks and printf()

So I'm quite puzzled by this one, taking this minimal example:

include.h:

#ifndef INCLUDE
#define INCLUDE

#include <gb/gb.h>

extern UINT8 bank;
extern UINT8 next;

void bank1_init();
void bank1_test();

void bank2_init();
void bank2_test();

#endif

bank1.c:

#include <gb/gb.h>
#include <stdio.h>

#include "include.h"

#pragma bank 1

void
bank1_init()
{
	printf("Welcome to bank 1.\nPRESS START\n");
}

void
bank1_test()
{
	if (joypad() & J_START)
	{
		printf("Good work!\n");
		next = 2;
	}
}

bank2.c:

#include <gb/gb.h>
#include <stdio.h>

#include "include.h"

#pragma bank 2

void
bank2_init()
{
	printf("Welcome to bank 2.\nPRESS SELECT\n");
}

void
bank2_test()
{
	if (joypad() & J_SELECT)
	{
		printf("Good work!\n");
		next = 1;
	}
}

main.c:

#include <gb/gb.h>
#include <stdio.h>

#include "include.h"

UINT8 bank;
UINT8 next;

void
main(void)
{
	bank = 1;
	next = 1;
	
	//printf("HELLO.\n");
	SWITCH_ROM_MBC5(bank);
	bank1_init();
	
	while (1)
	{
		wait_vbl_done();
		
		switch (bank)
		{
			case 1:
				bank1_test();
				break;
				
			case 2:
				bank2_test();
				break;
		}
		
		if (next != bank)
		{
			SWITCH_ROM_MBC5(next);
			
			switch (next)
			{
				case 1U:
					bank1_init();
					break;
					
				case 2U:
					bank2_init();
					break;
			}
			
			bank = next;
		}
	}
}

This program compiles OK (bank1.c goes to ROM bank 1 and bank2.c to bank 2) and it should work, but it doesn't. The strange thing is that, if we uncomment the line that says printf("HELLO.\n"); (main.c), it works.

Also, I have tested it with past versions of GBDK-2020, and found that it works with release 3.0.1 (with the printf commented out, as it should).

Any explanation for this behavior?

Also, if I comment out the first bank switch, it stops working too. Shouldn't bank 1 be active by default?

?ASlink-Error-<cannot open> : "colorbar.ihx"

I compile a GBC Example from the GBDK-2020 Color Bar Example folder

But it said a linking error: ?ASlink-Error-<cannot open> : "colorbar.ihx"
Is there something missing, is it a bug or am I doing it wrong?

License of some files is plain LGPL with no SDCC exception

In most files that have LGPL license, there is an exception to use them with SDCC:

https://github.com/Zal0/gbdk-2020/blob/d7265ebb0e80e2bd2c365161a864bede3ac2292c/gbdk-lib/libc/asm/gbz80/mul.s

But there are a few files that don't have the exception:

https://github.com/Zal0/gbdk-2020/blob/d7265ebb0e80e2bd2c365161a864bede3ac2292c/gbdk-lib/libc/_modulong.c
https://github.com/Zal0/gbdk-2020/blob/d7265ebb0e80e2bd2c365161a864bede3ac2292c/gbdk-lib/libc/_modslong.c
https://github.com/Zal0/gbdk-2020/blob/d7265ebb0e80e2bd2c365161a864bede3ac2292c/gbdk-lib/libc/_divslong.c

This means that some closed-source games that are using the division functions introduced by the compiler are not complying with the library. It's unlikely that many games are affected, though, as it affects 32 bit division, which is probably uncommon.

lcc determines it's directory wrongly

Calling lcc as gbdk-2020/build/gbdk/bin//lcc does not work, but there shouldn't be a difference to gbdk-2020/build/gbdk/bin/lcc

How do I set the ROM's title?

I'm compiling a ROM with GBDK, but it doesn't save a game name in the header. How do I add a game name?

memcpy() and memset() not working

Taking the following minimal example:

#include <gb/gb.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

typedef struct ExampleStruct
{
	UINT8 number1;
	UINT8 number2;
};

void main(void)
{
	struct ExampleStruct struct1;
	struct1.number1 = 10;
	struct1.number2 = 20;
	printf("number1: %u\n", struct1.number1);
	printf("number2: %u\n", struct1.number2);
	
	struct ExampleStruct struct2;
	struct2 = struct1;
	printf("number1: %u\n", struct2.number1);
	printf("number2: %u\n", struct2.number2);
	
	memset(&struct1, 0, sizeof(struct ExampleStruct));
	printf("number1: %u\n", struct1.number1);
	printf("number2: %u\n", struct1.number2);
}

Compiling fails with:

warning 112: function 'memset' implicit declaration
error 101: too many parameters

Linking fails with:

?ASlink-Warning-Undefined Global ___memcpy referenced by module

The same code works correctly when using gbdk-n.

Strangely enough, memcpy(0, 0, 0) links correctly.

malloc() does not work either but I seem to recall that it was broken, right?

Build instructions

Please add build instructions somewhere
Also, write a proper readme.md

lcc -S makes rel-file instead of binary rom

lcc -S -o test.gb test.c
produces test.gb which is not a binary rom, but an object file, that should be linked and then converted to the binary file with makebin.

"WIN32 Binaries" might be misleading

I thought the term "WIN32 Binaries" might be misleading because they are actually built with Mingw-w64. Here are my steps to discover:

wget https://github.com/Zal0/gbdk-2020/releases/latest/download/gbdk-win.zip
unzip gbdk-win.zip 
file gbdk/bin/sdcc.exe

It shows "PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows" while lcc.exe would be dedicated to 32-bit:

gbdk/bin/lcc.exe: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows

In other words, current "WIN32 Binaries" is the mixture of x86 and x86-64 executable files. In order to make "WIN32 Binaries" work, 64-bit Windows are required.

bank overflow checking in LCC

that should be done in SDCC's makebin tool, but we might wait for a decade for that, so, it is nice to implement that ourselves instead, that is easy: https://gbdev.gg8.se/forums/viewtopic.php?pid=4540#p4540

Simplify debug mode

It would be easier if lcc would just accept --debug and then set --debug for the compiler and -y for the linker

Example ram_fn not working

ram_fn doesn't compile. It says

C:\Users\Zalo\Desktop\gb\gbdk-2020\build\ppc-unknown-linux2.2\gbdk\examples\gb>..\..\bin\lcc -Wa-l -Wl-m -Wl-j -c -o ram_fn.o ram_fn.c
ram_fn.c:48: warning 84: 'auto' variable 'inc_ram' may be used before initialization
ram_fn.c:58: warning 84: 'auto' variable 'inc_hiram' may be used before initialization
ram_fn.c:48: warning 84: 'auto' variable 'inc_ram' may be used before initialization
ram_fn.c:58: warning 84: 'auto' variable 'inc_hiram' may be used before initialization

C:\Users\Zalo\Desktop\gb\gbdk-2020\build\ppc-unknown-linux2.2\gbdk\examples\gb>..\..\bin\lcc -Wa-l -Wl-m -Wl-j -Wl-g_inc_ram=0xD000 -Wl-g_inc_hiram=0xFFA0 -o ram_fn.gb ram_fn.o

?ASlink-Warning-Undefined Global ___inc_start referenced by module C__Users_Zalo_AppData_Local_Temp⌠U2-

?ASlink-Warning-Undefined Global ___inc_end referenced by module C__Users_Zalo_AppData_Local_Temp⌠U2-

Building gbdk-lib on ubuntu fails

make -C libc
make[1]: Entering directory '/mnt/c/development/magazine_repo/gbdk-2020/gbdk-lib/libc'
for i in gbz80; do make port THIS=$i PORT=$i; done
make[2]: Entering directory '/mnt/c/development/magazine_repo/gbdk-2020/gbdk-lib/libc'
rm -f  *.o *.cdb *.sym *.lst *~ *.asm
if [ -e global.s ]; then \
        sed -e "s/.NEAR_CALLS\W=\W[0-9]\+/.NEAR_CALLS = 1/" global.s > tmp1.txt ;\
        mv tmp1.txt global.s; \
fi
mkdir -p ../build/small/asxxxx/gbz80
/bin/sdcc -I../include -DSDCC_z80 -D__gbz80 -mgbz80 -DGBDK=1 -c -o ../build/small/asxxxx/gbz80/bsearch.o bsearch.c
make[2]: /bin/sdcc: Command not found
../libc/rules-asxxxx.mk:7: recipe for target '../build/small/asxxxx/gbz80/bsearch.o' failed
make[2]: *** [../build/small/asxxxx/gbz80/bsearch.o] Error 127
make[2]: Leaving directory '/mnt/c/development/magazine_repo/gbdk-2020/gbdk-lib/libc'
Makefile:31: recipe for target 'ports' failed
make[1]: *** [ports] Error 2
make[1]: Leaving directory '/mnt/c/development/magazine_repo/gbdk-2020/gbdk-lib/libc'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

Build fails when installing SDCC (last step)

On Linux Ubuntu 19.10 (64-bit), GBDK-2020 builds correctly, but the last step fails with:

Installing SDCC
cp: cannot stat '/usr/bin/{as2gbmap,makebin,packihx,sdar,sdasgb,sdcc,sdcdb,sdcdb{,src}.el,sdcpp,sdldgb,sdnm,sdobjcopy,sdranlib,sz80}': No such file or directory
make: *** [Makefile:213: sdcc-install] Error 1

I copied the command and ran it myself, and all those files exist but 4:

cp: cannot stat '/usr/bin/sdcdb': No such file or directory
cp: cannot stat '/usr/bin/sdcdb.el': No such file or directory
cp: cannot stat '/usr/bin/sdcdbsrc.el': No such file or directory
cp: cannot stat '/usr/bin/sz80': No such file or directory

Also, it seems Make is not correctly interpreting that line (/usr/bin/{as2gbmap,makebin,packihx,sdar,sdasgb,sdcc,sdcdb,sdcdb{,src}.el,sdcpp,sdldgb,sdnm,sdobjcopy,sdranlib,sz80}), it is feeding it literally to cp without expanding the curly braces to get the individual file names.

using initarand() and arand() leads to random code execution (gbdk 4.0, linux)

I haven't identified the specific problem, but it looks like calling initarand() and arand() will cause the current program to eventually start executing random code (at least in one case SP decrements endlessly).

You can test this with the "rand.c" sample (or "dscan" sample which also uses arand). It typically takes about 10-13 iterations of the main loop before something bad happens. If it is changed to only use initrand() and rand() the problem does not appear to manifest.

At first glance it does not seem like changes to arand.s (vs 2.95) are the source of the problem.

For reference, the rand.c sample from the gbdk 2.95 built against 2.95 does not look like it has this problem.

stdint.h, limits.h missing

I recently made an optimized abs routine in assembly to replace the one written in C. The tests I made use the constants INT_MIN and INT_MAX from limits.h, but limits.h is not available (as well as stdint.h).

Is there a way to fix this? Am I missing something?

bsearch.c build error

Output:

bsearch.c:33: syntax error: token -> 'const' ; column 10
bsearch.c:33: syntax error: token -> ')' ; column 37
bsearch.c:38: error 20: Undefined identifier 'c'
bsearch.c:40: error 20: Undefined identifier 'c'
bsearch.c:42: error 20: Undefined identifier 'left'
bsearch.c:42: error 20: Undefined identifier 'middle'
bsearch.c:46: error 20: Undefined identifier 'middle'
-:0: warning 154: converting integral to pointer without a cast
from type 'int fixed'
to type 'void generic* fixed'
-:0: warning 85: in function bsearch unreferenced function argument : 'key'
-:0: warning 85: in function bsearch unreferenced function argument : 'base'
-:0: warning 85: in function bsearch unreferenced function argument : 'compar'
bsearch.c:49: syntax error: token -> 'return' ; column 7
../libc/rules-asxxxx.mk:7: recipe for target '../build/small/asxxxx/gbz80/bsearch.o' failed
make[2]: *** [../build/small/asxxxx/gbz80/bsearch.o] Error 1
Makefile:31: recipe for target 'ports' failed
make[1]: *** [ports] Error 2
Makefile:150: recipe for target 'gbdk-lib-build' failed
make: *** [gbdk-lib-build] Error 2

strcmp ignores first character of string

Consider the following test code:

#include <stdio.h>
#include <string.h>
char abc[] = "abc";
char xbc[] = "xbc";
char abx[] = "abx";
char abcd[] = "abcd";

void main(){
	printf("%s %s %d\n", abc, abc, strcmp(abc,abc));
	printf("%s %s %d\n", abc, xbc, strcmp(abc,xbc));
	printf("%s %s %d\n", xbc, abc, strcmp(xbc,abc));
	printf("%s %s %d\n", abc, abx, strcmp(abc,abx));
	printf("%s %s %d\n", abx, abc, strcmp(abx,abc));
	printf("%s %s %d\n", abc, abcd, strcmp(abc,abcd));
	printf("%s %s %d\n", abcd, abc, strcmp(abcd,abc));
}

The output should be

abc abc 0
abc xbc -1
xbc abc 1
abc abx -1
abx abc 1
abc abcd -1
abcd abc 1

However, the output is actually

abc abc 0
abc xbc 0
xbc abc 0
abc abx -1
abx abc 1
abc abcd -1
abcd abc 1

This is because of the jump to 1$ which jumps directly to incrementing the pointers. Maybe copied from the pattern used in _memcpy or originating from a prefix increment instead of a postifx increment in the original code... PR incoming soon with a fix and a couple other small changes to strcmp.

; int strcmp(const char *s1, const char *s2) 
_strcmp::
	lda	hl,2(sp)
	ld	a,(hl+)
	ld	e, a
	ld	a,(hl+)
	ld	d, a
	ld	a,(hl+)
	ld	h,(hl)
	ld	l,a

	jr	1$
2$:	
	ld	a,(de)
	sub	(hl)
	jr	nz,4$
	;; A == 0
	cp	(hl)
	jr	z,3$
1$:	
	inc	de
	inc	hl
	jr	2$

Opt-in to Hacktoberfest

Hacktoberfest is opt-in this year, which means that the maintainer has to add the hacktoberfest topic to the repository for users to recieve credit for their pull requests.

See the official announcement.

lcc does not cleanup *.adb files from the temp folder when -Wf--debug is specified

subj! if you specify -tempdir=obj you will get plenty of those in the obj folder while recompiling your sources.

The prebuilt SDCC provides unnecessary ports other than gbz80

After extracting files from the v4.0 release, I found that the prebuilt sdcc provided unnecessary ports other than gbz80, such as mcs51, r2k, r3ka, pic16, etc. The only backend required by gbdk-2020 is gbz80, and other ports can be disabled with the following SDCC configuration:

./configure \
  --enable-gbz80-port \
  --disable-mcs51-port \
  --disable-z80-port \
  --disable-z180-port \
  --disable-r2k-port \
  --disable-r2ka-port \
  --disable-r3ka-port \
  --disable-tlcs90-port \
  --disable-ez80_z80-port \
  --disable-z80n-port \
  --disable-ds390-port \
  --disable-ds400-port \
  --disable-pic14-port \
  --disable-pic16-port \
  --disable-hc08-port \
  --disable-s08-port \
  --disable-stm8-port \
  --disable-pdk13-port \
  --disable-pdk14-port \
  --disable-pdk15-port

After disabling unnecessary ports in sdcc, the message dumped by sdcc is compact and meaningful:

SDCC : gbz80 4.0.4 #11952 (Linux)
...
Special options for the gbz80 port:
      -bo                   <num> use code bank <num>
      -ba                   <num> use data bank <num>
      --callee-saves-bc     Force a called function to always save BC
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --legacy-banking      Use legacy method to call banked functions

Merge or upstream libc where applicable

Merging files (.asm and .c) from gbdk-2020's libc with the one of sdcc could reduce time and effort needed for maintaining them.

ASM: SDCC (lib/gbz80/) does contain gameboy specific assembly files, in those cases we should upstream our (libc/asm/gbz80/) changes, unless the ones in sdcc are better, but I do not expect that.

C: For cases where both use c files, sdcc's should be used and maybe improved. They do allow target specific inline assembly and code chunks selected with preprocessor switches.

I don't know if it is possible to selectively override some functions from sdcc and fall back it's standard library in all other cases. That should be investigated.

This is in general about investigating, comparing and for asm also counting the cycles.

Discord link expired

Readme.md the gbdk discord link has become invalid

Makefile:220: *** SDCCDIR is undefined. Stop. Raspbian on Raspberry Pi 4

Hello, I'm building on Raspberry Pi 4 everything has been carefully configured in order to compile correctly, after the download and installation of SDCC in the home folder I exported variables like so:

export PATH=$PATH:/home/pi/sdcc/bin
export SDCCDIR=/home/pi/sdcc

As you can see this is the printenv result:

SDCCDIR=/home/pi/sdcc
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/pi/sdcc/bin

This is the content of the home folder:

pi@raspberrypi:~ $ ls
gbdk-2020-4.0.2 sdcc sdcc-snapshot-armv6l-unknown-linux-gnueabihf-20210121-12016.tar.bz2

when I try to sudo make this is the error:

Makefile:220: *** SDCCDIR is undefined. Stop.

This has been performed on a fresh new Raspbian installation on a Raspberry Pi 4.

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux

I hope the information i provided are enought to replicate the issue because I do not know why the makefile is unable to locate SDCC even if the SDCCDIR has been properly configured.

Thank You

SDCC copy at end of build broken for Windows

@untoxa @jserv

Building on a Win10 x64 VM (that previously built ok) - I'm getting an error on SDCC binary copy at the end. Seems related to the changes merged in PR #88

Everything else builds fine.

If I revert the copy to the previous method it copies with no problem.

ifeq ($(OS),Windows_NT)
		@cp -r $(SDCCDIR)/bin $(BUILDDIR)
else

SDCCDIR is set as :
SET SDCCDIR=C:\gb\sdcc

Here is the console log

cp: cannot stat `C:gbsdcc/bin/as2gbmap.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/makebin.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/packihx.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdar.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdasgb.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdcc.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdcdb.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdcdb.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdcpp.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdldgb.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdnm.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdobjcopy.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sdranlib.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/sz80.exe': No such file or directory
cp: cannot stat `C:gbsdcc/bin/libgcc_s_seh-1.dll': No such file or directory
cp: cannot stat `C:gbsdcc/bin/libgcc_s_sjlj-1.dll': No such file or directory
cp: cannot stat `C:gbsdcc/bin/libstdc++-6.dll': No such file or directory
cp: cannot stat `C:gbsdcc/bin/libwinpthread-1.dll': No such file or directory
cp: cannot stat `C:gbsdcc/bin/readline5.dll': No such file or directory
make: *** [sdcc-install] Error 1```

Can't compile for arm

I want to use this on an server made from a raspberry pi 3b+ running Ubuntu server 20.10 or Raspbian. SDCC cannot be compiled by me. Maybe I'm stupid, idunno. Any chance for an arm binary release? Please?

gcc is installed but sdcc confire cpp fails sanity check...

Info for Build on Raspberry Pi

Hello I would like to compile for Raspberry Pi, actually i'm using a pi 400, but i do not know how retrive the required version of sdcc, on the repository is writter that is required: sdcc nightlies from 4.0.7 #12016 onwards but on the link provided i didn't found this version. Can someone help me out ?

lcc fails to compile into IHX

lcc -o rom.ihx src/graphics.c src/main.c src/map2buf.c

produces binary rom with the IHX extension, not Intel HEX.

GBC Color Support

I can't do background palettes for gbc because it pops up this error:
C:/GBDK-2020/include/gb/cgb.h:40: syntax error: token -> 'first_palette' ; column 35

Am I doing palettes wrong or is the header file wrong?

Palette code:

const UWORD warningPalettes[] = {
    RGB_WHITE, RGB_CYAN, RGB_RED, RGB_DARKGREEN
};

and I load the palette with:
set_bkg_palette(0, 1, &warningPalettes[0]);

GPL violation

So I noticed that some files say that they are GPL'd
https://github.com/Zal0/gbdk-2020/blob/develop/gbdk-lib/libc/__assert.c
https://github.com/Zal0/gbdk-2020/blob/develop/gbdk-lib/libc/_divslong.c
https://github.com/Zal0/gbdk-2020/blob/develop/gbdk-lib/libc/_divulong.c
However, the license is MIT, and GPL code in an MIT project is not legally possible

lcc defines .STACK=0xDEFF instead of 0xE000

we loose 257 bytes of WRAM for no reason

Building colorbar example is broken (v4.0, Linux)

I've turned on -v for the link stage of the make file to show more detail.

$ make
../../../bin/lcc -Wa-l -Wl-m -DGBDK_2_COMPAT -c -o colorbar.o colorbar.c
../../../bin/lcc -Wa-l -Wl-m -DGBDK_2_COMPAT -v -Wl-yC -o colorbar.gb colorbar.o
../../../bin/lcc $Id: lcc.c,v 1.6 2001/10/28 18:38:13 michaelh Exp $
"../../../"bin/sdldgb -n -i -m -y C -g _shadow_OAM=0xC000 -g .STACK=0xDEFF -g .refresh_OAM=0xFF80 -b _DATA=0xc0a0 -b _CODE=0x0200 -k "../../../"lib/small/asxxxx/gbz80/ -l gbz80.lib -k "../../../"lib/small/asxxxx/gb/ -l gb.lib colorbar.ihx "../../../"lib/small/asxxxx/gb/crt0.o colorbar.o
?ASlink-Error-<cannot open> : "colorbar.ihx"
Makefile:26: recipe for target 'colorbar.gb' failed
make: *** [colorbar.gb] Error 1

Is the flag passed to the linker supposed to have that space in "-y C"?
And, should it be getting passed to makebin?

copies all ${SDCCDIR}/bin to SDCC

When I do an install a bunch of unnecessary files are copied (all of /usr/bin.)

I am working on this complete docker dev environment for gameboy. It currently uses gbdk-n but that lib has some issues that make it not really workable, so I'd like to switch to this one. When I run this:

export SDCCDIR=/usr
git clone https://github.com/Zal0/gbdk-2020.git /opt/gbdk \
  && cd /opt/gbdk \
  && make && make install

I notice it copies all of ${SDCCDIR}/bin, which in this case is a lot of things. I'd like to use the OS-installed copy of sdcc, if possible.

I'd recommend copying (or better: sym-linking) just the sdcc bin files, which is this:

as2gbmap
makebin
packihx
sdar
sdas390
sdas6808
sdas8051
sdasgb
sdasrab
sdasstm8
sdastlcs90
sdasz80
sdcc
sdcclib
sdcpp
sdld
sdldstm8
sdnm
sdobjcopy
sdranlib
sdld6808
sdldgb
sdldz80

Maybe even not copy or symlink, and just rely on path, if sdcc is in it.

For information, this is the version that comes with docker's current debian:latest container, if you install sdcc package:

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/TININative/ds400/hc08/s08/stm8 3.8.0 #10562 (Linux)

lcc -S doesn't give assembly

Store in abs.c:

int abs(int a)
{
    return a < 0 ? -a : a;
}

run lcc -S test.c; nothing new in the directory
run lcc -S test.c -o test.asm; no test.asm created
run lcc -S test.c -o -; assembly not output to stdout

running GBDK v4.0 on Linux

support for unit-testing

found some issues with newely written code, i wish code was covered with unit-tests.

list of possible improvements for current functions

lets make a list of possible improvements and optimizations here. if at some point we'd get testing facility that can test the functions for expected behaviour, then we could test those.
https://gist.github.com/ISSOtm/c9b0efab55108ce63bfeb775525c8c2c/ - set_xxx_data family

Homebrew Formula

It would be great if GBDK had a Homebrew formula to make it easier to install the tools on macOS.

Thanks so much for your work on this project!

Building examples failing on Linux

When I run make, to build the examples, I get the following output for each example (redundant lines redacted):

../../bin/lcc -Wa-l -Wl-m -Wl-j -o galaxy.gb galaxy.o
Error: Format(XL3) Only XL2 format is supported
Error: Format(XL3) Only XL2 format is supported
Error: Format(XL3) Only XL2 format is supported
[83 lines redacted]
Error: Format(XL3) Only XL2 format is supported
Error: Format(XL3) Only XL2 format is supported
WARNING: possibly wrote twice at addr 0 (00->00)
WARNING: possibly wrote twice at addr 10 (00->00)
WARNING: possibly wrote twice at addr 1d (00->10)
WARNING: possibly wrote twice at addr 40 (00->00)
WARNING: possibly wrote twice at addr 40 (00->00)
WARNING: possibly wrote twice at addr 48 (00->00)
WARNING: possibly wrote twice at addr 48 (00->00)
WARNING: possibly wrote twice at addr 48 (00->00)
WARNING: possibly wrote twice at addr 50 (00->00)
WARNING: possibly wrote twice at addr 50 (00->00)
WARNING: possibly wrote twice at addr 50 (00->00)
[56 lines redacted]
WARNING: possibly wrote twice at addr 1e0 (00->00)
ERROR: address overflow (addr c0bd >= 8000)
Makefile:37: recipe for target 'galaxy.gb' failed
make: *** [galaxy.gb] Error 1

I'm on Kubuntu 18.04 and used sdcc-snapshot-amd64-unknown-linux2.5-20200904-11846.tar.bz2 when building GBDK. I used GBDK release 3.2.

Any help would be appreciated.

Update version reported by Lcc

Well, it's not 2001 anymore. Any objections to updating the version, date and author reported by lcc?

Does anything rely on or test for that specific string?

v 1.6 2001/10/28 18:38:13 michaelh Exp $";

How about this, and perhaps building the date of compilation into the string?
v 2.0 2020/12/01 18:38:13 gbdk2020 Exp $";

GBDK-2020 can not find SDCC binaries in Fedora

I am running the latest version of Fedora (33). I installed SDCC from the repositories using:

sudo dnf install sdcc

When I tried to compile GBDK-2020 I got several errors, because the Makefile could not find the SDCC binaries. I browsed /usr/bin and discovered that they had been installed using different names; instead of sdcc I got sdcc-sdcc, instead of sdar I got sdcc-sdar, and such (each binary had sdcc prepended to its name). The binaries I have are:

sdcc-as2gbmap
sdcc-makebin
sdcc-packihx
sdcc-s51
sdcc-sdar
sdcc-sdas390
sdcc-sdas6808
sdcc-sdas8051
sdcc-sdasgb
sdcc-sdaspdk13
sdcc-sdaspdk14
sdcc-sdaspdk15
sdcc-sdasrab
sdcc-sdasstm8
sdcc-sdastlcs90
sdcc-sdasz80
sdcc-sdcc
sdcc-sdcdb
sdcc-sdcpp
sdcc-sdld
sdcc-sdld6808
sdcc-sdldgb
sdcc-sdldpdk
sdcc-sdldstm8
sdcc-sdldz80
sdcc-sdnm
sdcc-sdobjcopy
sdcc-sdranlib
sdcc-shc08
sdcc-spdk
sdcc-sstm8
sdcc-stlcs
sdcc-sz80

I solved this problem by creating symlinks to the tools GBDK needs, but I suggest that some check is added to the Makefile so, if this is the case, it can locate the correct binaries.

LCC handles paths with spaces incorrectly in windows

if you try to build examples with gbdk in "C:\Program` Files (x86)" folder you get:

C:\Program` Files (x86)\gbdk\examples\gb>..\..\bin\lcc -Wa-l -Wl-m -Wl-j -c -o paint.o paint.c
..\..\bin\lcc: C:\Program: Invalid argument

that's because it does not escape paths that contain spaces with double quotes, like:

"c:\program files (x86)\gbdk\bin\sdcc\bin\sdcc.exe"

Docs URL does not appear to work

The URL listed on the README is for https://zal0.github.io/gbdk-2020/docs/api which is a 404. Wondering if this could get fixed?

Lots of warnings

The code is really old and the new compiler spits a lot of warnings that need to be fixed

`printf` works incorrectly on data types smaller than `int`

Reported by a user on the Discord server: printf("%u\n", (UINT8)0); prints a garbage value (3072 for them), but printf("%u\n, (int)0); works correctly.

This appears to stem from an incompatibility between the function's calling convention (preventing integer promotion) and the function's behavior (expecting promotion).

BGB generates exception "non-standard MBC writes" when calling main()

That happens because far_fixer determines the code of main() to be in bank0, and patches the code with 0. And switching bank0 in MBC1 makes bank1 active which is considered "non standard" by BGB.
Also, when switching bank to 0 with MBC5, makes two copies of bank0 being active at the same time by different addresses. That is mostly useless.
I suggest to force setting bank1 when the code of the function is located in _CODE (to make _CODE asias of _CODE_1). That results in exactly the same behaviour with MBC1, and with MBC5 that results into unification with MBC1, which is also good. That also suppress the silly BGB exception.
We should to that only for _CODE area, not for _HOME and other possible encounters, because banked calls into _HOME or _BASE should never happen (they may, if you make errors in your C-code, for example, declare function as __nonbanked in .C and __banked in .H -- that is error, and BGB exception must raise here).

sdcc --debug switch breaks the far_fixer

if you set the --debug commandline switch for the SDCC, it emits additional info to object files:
;!FILE build\ISO.c.asm XL2 H 7 areas 929 global symbols M ISO O -mgbz80 S _r2 Ref0000 S _clear_map Ref0000 S _draw_to_shadow_XY Ref0000
so that comment in the first line breaks the far_fixer embedded into the linker, so we get this error:
Error: Format(;!FILE) Only XL2 format is supported
it takes the first string of a file as a file format definition, while it should take the first not empty and not commented out (e.g. begins with ";") string.

race condition in .set_xy_tt

WAIT_STAT
LD	A, (HL+)
LD	(BC), A

stat register should be rechecked post-write.
also, interrupts should be disabled during check, write and re-check.

<gb/drawing.h>bug

Seems drawing.c has a bug with line function.

line(50,50,23,22); is for example not drawing correctly. It seems 23,22 is correctly targeted, but 50,50 is not.

Tested with BGB version 1.5.8

is __mullong meant to be excluded?

https://github.com/Zal0/gbdk-2020/blob/0dd6c6f48fd095bfb710e6adda71b6bdc573bcf3/gbdk-lib/libc/_mullong.c

this code seems to be in GBDK but if I try and multiple two long values in my code I get:

?ASlink-Warning-Undefined Global '__mullong' referenced by module 'main'

When I try and compile using lcc