> At the moment I have not been able to install sdcc as the instructions indicate, as it gives me error and does not create the files "sdcc" or "sdcpp".
I'll try a build from scratch for sdcc again to verify nothing's gone wrong. If you have access to windows, the nightly build includes everything including sdcc - all you need to do is set up the ZCCCFG environment variable and update PATH.
I updated my original link with your changes:
https://github.com/z88dk/z88dk/issues/87
I completed the header/implementation separation and only made a few small changes:
* I put brackets around a couple of the macro arguments in the #define expansion
* I moved the inline asm implementation of msx_KeyPressed() from globales.c to globales.asm.
At the end of this section (
https://www.z88dk.org/wiki/doku.php?id= ... y_language ) there is some talk about why asm and c should be completely separated. In this case it's more a matter of style than technical. I did change the calling convention from standard to fastcall so that the parameter would be in HL when the function starts.
* const unsigned char* lista_tiles_t_colision[48] = {1,1,1,1,1,1,1,1...};
This is an arrary of unsigned char not pointers to unsigned char.
* asm("halt");
This syntax is not understood by sdcc. In the interest of making this compatible with both compilers this is preferable:
__asm
halt
__endasm;
In sdcc's case, inlined asm disrupts code optimization so we invented "intrinsics" which is a way to inline simple asm instructions without disturbing optimization. So I replaced instances of those two asm("halt"); with the equivalent intrinsic:
intrinsic_halt();
After I did that I found out the classic library does not have the intrinsic header yet. So for now I added:
#ifdef Z88DK_USES_SDCC
extern void intrinsic_halt(void) __preserves_regs(a,b,c,d,e,h,l);
#else
extern void __LIB__ intrinsic_halt(void) __smallc;
#endif
at the top of FallOfPrometheus.c. The toolchain is properly processing these intrinsics but the classic library has nothing to inform the compilers about them yet. I'll add the missing intrinsic.h in the next day or two, after which if you update you can replace that mess with "#include <intrinsic.h>"
I put that small amount of effort in for sdcc so we can get sdcc working on your code as well.
I added the file "zproject.lst" to list all the source code files in your project. I'm running on Windows where make is not standard so I'm compiling using a different compile line:
zcc +msx -O3 -subtype=rom -create-app -m --list -o FoP @zproject.lst
This will work on any OS but the disadvantage versus a makefile is it compiles everything regardless of whether files have been updated. This makes little difference to sccz80 as sccz80 compiles quickly but I'm exceeding 15 minutes compile time for your program on sdcc with optimization turned high. For sdcc and optimization high, makefiles can make a difference.
With the compile line above, I get something that works and the result is the same for -O2 and -O3. At O3, the code size is 24649 bytes, DATA is 9 bytes and BSS is 104 bytes so total ram usage is 113 bytes plus stack which is very little.
If I add "-pragam-define:CRT_MODEL=2" to select the compressed compile, the program hangs. This is a bug I am investigating now.
A compile line using sdcc:
zcc +msx -compiler=sdcc -subtype=rom -create-app -m --list -o FoP @zproject.lst
Seg faults on the last source file tileset_t.c and this is the second bug I'm looking at now. Nevertheless, sdcc complains a lot and I find it easier to find bugs with it.
That compile is at minimal optimization level; a high optimization level would look like this:
zcc +msx -compiler=sdcc -SO3 --max-allocs-per-node200000 -subtype=rom -create-app -m --list -o FoP @zproject.lst
(and optionally --opt-code-size)
That one was taking 15 minutes before I stopped it and opted for the low optimization compile. Maybe once it works and you're looking for good code rather than bug fixing, you can set aside some time to try a high optimization compile.