Problem generating MSX ROM

[eldeljar]

Hi, I recently started developing a MSX game with z88dk (version 199B), but I have encountered a problem when it comes to generating the ROM. I am compiled with the following parameters:

Zcc + msx -subtype = rom -create-app -lmalloc -lm -lndos -m -g -s -no-cleanup -O3

This command generates a .bin (10Kb) and an .rom that when loaded with an emulator, the menu screen is displayed correctly, but the following screen does not work correctly.

The error has started when the .bin has exceeded 9Kb, so it seems that the binary is not being generated correctly and at some point the stack overwrites the data.

Can anyone tell me what configuration file I can check or what can I do to fix it?

Thank you very much

[alvin]

Just adding some information:

The CODE address is 0x4000 by default.
The BSS+DATA sections are ORGed at 0xc000 by default.
The stack pointer is initialized with "ld sp,($fc4a)".

You should see two separate "foo_BSS.bin" and "foo_DATA.bin" binaries produced. Those two added together are placed at address 0xc000 and they must be able fit there as well as give enough space for the stack to grow. I'm not an expert on the msx so I am not sure what "ld sp,($fc4a)" initializes sp to; you'd probably want 256 bytes of space for the stack.

Would you mind trying something to see if the problem is in the msx crt?

Create a file "zpragma.inc" containing the following:

Code: Select all

#pragma output CRT_ORG_CODE = 0x4000
#pragma output CRT_ORG_BSS = 0xc000

Then add "-pragma-include:zpragma.inc" to your compile line.

It looks to me like these values are being set inside the msx crt but they are not communicated to appmake which builds the .rom and .bin.

[eldeljar]

Hello, thanks for the answer.

I have tried to create the file "zpragma.inc" and conpile with the option "-pragma-include: zpragma.inc", and it indicates that the variable "CRT_ORG_CODE" already exists. I have removed it and it does not give error but continues to malfunction.

The game_bss_crt.bin file has a size of 70 bytes, and the file game_DATA.bin has a size of 7.8kB, so I guess there is enough space left to the stack.

The appmake call that is displayed when compiling is:

Appmake + rom --romsize = 0x8000 --rombase = 0x4000 -b game.bin -c / tmp / tmpXX6bB8Rk

I am not sure if the problem is the stack: if I try to comment some calls to functions, then the program does not work correctly. However, if I delete the calls to those functions and their source code, the program works.

I'm trying to check the game.map to see the memory locations, but at the moment I have not found anything strange:

- Code starts at position 0x4000
- The data starts at position 0xC000

This is the first time I see a .map file, so I may not be reviewing it well.

Any other suggestions?

[alvin]

I've looked into it further and the extra pragmas are not needed (and didn't make a difference as you saw).

A compile of this:

Code: Select all

// zcc +msx -subtype=rom -create-app -lndos -m -O3 test.c -o test.bin

#include <stdio.h>

void main(void)
{
        printf("\nsp = %u\n", *(unsigned int *)(0xfc4a));
}

printed out 62336 under emulation on a 128k msx machine so that means 13184 bytes for data/bss/stack. Are you using a heap (for malloc, etc)? That will have to be in there too.

It's hard to guess what is going on without seeing some source code after this point. Is there any way you could zip it up someplace so we can try to compile?

I'll mention that your data section is quite large (7.8k) - you should try compiling using the compressed rom model (add "-pragma-define:CRT_MODEL=2" to the compile line). The data section contains ram variables that are initially non-zero. In order to properly initialize at startup, a copy of that data section has to be stored in rom and then this is copied into ram before main is called. The compressed rom model stores a compressed copy of your data section instead of a 1:1 copy that would occupy 7.8k in your rom.

I supposed that's the other question: is your "game.bin" file < 32k? This will include the stored data section but I suspect there is no problem there because appmake didn't complain.

[eldeljar]

Thanks again for the reply.

I added the "-pragma-define: CRT_MODEL = 2" option on the command line and now everything works for me:

Code: Select all

ZX7: Optimal LZ77 / LZSS compression by Einar Saukas
File converted from 7842 to 2612 bytes! (Delta 3)

I am a newbie in video game development, so it is possible that I have errors in the code and that the code is not very optimized.

For example, at the moment I do not have tilemaps with compression, since I do not know how to do it. In z88dk is the tool zx7 to compress, but then I do not know how to unzip the data.

I have not added music to the game yet, because I do not know how to do it, although I will open a new post to ask. Wyztracker, Vortex Tracker, etc.?

Thank you very much for the help.

[alvin]

I added the "-pragma-define: CRT_MODEL = 2" option on the command line and now everything works for me:

Code: Select all

ZX7: Optimal LZ77 / LZSS compression by Einar Saukas
File converted from 7842 to 2612 bytes! (Delta 3)

I am a newbie in video game development, so it is possible that I have errors in the code and that the code is not very optimized.

This reduces the size of the binary stored in rom by about 5k. The fact that this seems to work suggests that your program is large (and was) > 32k? Maybe have a look at the size of your "game.bin" or "game" file after a compile. Appmake should complain if the binary won't fit into the 32k but if the 32k is not being exceeded the failure is still mysterious.

For example, at the moment I do not have tilemaps with compression, since I do not know how to do it. In z88dk is the tool zx7 to compress, but then I do not know how to unzip the data.

With CRT_MODEL=2 your tile data is being stored in compressed form on the cartridge rom but it is being decompressed all at once into ram at startup. If you start to have ram issues, you'll likely have to go to a method where you stored each level's tilemap in compressed form and only decompress each level as required.

The classic library does have the zx7 decompression routine in its z80 library (that's why CRT_MODEL=2 works) but there is no c interface there. You'd have to add that manually, and I can show you how if you need it, but I will also open an issue for it ( https://github.com/z88dk/z88dk/issues/70 ) so that it gets included in the current build. You may prefer to update to the current build instead after it's done.

I have not added music to the game yet, because I do not know how to do it, although I will open a new post to ask. Wyztracker, Vortex Tracker, etc.?

These players produce an assembly code subroutine that should be called on each 50/60Hz interrupt. It's fairly easy to do this (although I am not familiar with msx specifics offhand) but the main difficulty is that these players quite often do not produce code that is easily usable. They are meant to be but the authors are not very familiar with cross development issues. For example, the players often contain self-modifying code. You can't store self-modifying code on a rom cartridge. z88dk does make it easy to use that code, however, as you can just assign it to a "smc" section but what that means is the code will be copied out of the rom cartridge and into ram at startup. In total, the player occupies 2x its size in memory at runtime (one for the rom copy and one for the active copy in ram). These routines also almost always assume one AY chip and that's not always the case for all computers and their add-ons. We've been a bit slow about it, but for these reasons the wyz/vt/etc trackers largely need rewrites.

[eldeljar]

Hi, the .bin file has never reached 32KB, currently the size is 10KB.

From the zx7 tool, I had already read something about it. At the moment I do not need them, since I only have 2 screens.

Regarding music, z88dk has several functions related to sound, and in particular the MSX library has functions for PSG sound, but I do not make a melody and I have not found examples. So I will try to use other tools for music. Anyway, I still will not start with the music and I will leave it for the last.

Thanks for the help.

[Timmy]

Sorry, I'm not very often at this site, but be warned that the MSX's memory structure only gives about 32K of ROM and about 16K of RAM, but the 16K also has to support other system variables as well as the stack, your normal gaming variables and your uncompressed code.

So if you're using zx7, your program will be at most about 13k, while if you're not using compression the game can be using the full 32K of ROM instead.

[alvin]

Sorry, I'm not very often at this site, but be warned that the MSX's memory structure only gives about 32K of ROM and about 16K of RAM, but the 16K also has to support other system variables as well as the stack, your normal gaming variables and your uncompressed code.

Yes the "ld sp,(0xfc4a)" is supposed to put the stack at the top byte available in ram. The test program I ran showed sp was being set to 62336 which left a sizable 13184 bytes for ram resident variables and the stack. Eldejar's game was using < 8k of ram so this isn't a problem yet. Maybe other msx configurations offer less ram but the fact the game worked after compression indicates the amount of ram is not a problem and the failure is still mysterious.

So if you're using zx7, your program will be at most about 13k, while if you're not using compression the game can be using the full 32K of ROM instead.

A zx7-compressed game will always allow a bigger program. The data section -- all those variables that are declared initially not zero -- has to be stored in the rom for copying into ram at startup. In eldejar's game the data section is quite large at 7.8k. So in a non-compressed rom this would leave 32k-7.8k = 24.2k for the program. With a compressed rom, the 7.8k was reduced to 2.6k, leaving 32k-2.6k = 29.4k for the program meaning there is an additional 5k of codespace in the cartridge.

I'll point out that it's very important to distinguish between read only non-zero data and non-zero data when writing rom software. There is a short section "The Importance of CONST" written about it here: https://www.z88dk.org/wiki/doku.php?id= ... e_of_const

By declaring relevant data as const, the data is moved out of ram and into rom instead. So if you have level data that is declared like this:

unsigned int level[] = {0, 2, 3, 4, 5, 6, ...};

you can instead declare like this:

const unsigned int level[] = {0, 2, 3, 4, 5, 6, ...};

and have it moved into the rom instead of occupying ram space. Being in rom means your program can't change it which is exactly what const indicates.


When you're in a situation where there is more rom available than ram, using zx7 to decompress things as required can make the ram go further. One thing that is under-utilized is the obstack implementation in z88dk (although this is the new c library only at the moment). It's a light & simple memory allocator that allows memory to be allocated in order and then rolled back, which is the kind of thing you'd want to do when starting a level (allocation for enemies, level, etc) and ending a level (just roll back to the first allocation, no fragmentation at all). This kind of set up can be much easier on the ram.

[eldeljar]

Hi, I'm sorry to say that the problem has returned, but now it's different: when I run the game in the emulator it does not load and the system reboots.

Currently the size of the BSS file is 83 bytes, while the size of the BIN file is 11K.

The tiles, tilesmaps and sprites I'm defining with "const unsigned char". Some global variables also define them with "const" and later if I want to modify their value I use a pointer.

I attach the link to the game code in case someone can give me optimization tips or want to analyze the problem. I am using version 1.99B of z88dk. Keep in mind that I'm new to C and programming for MSX, and there are sure to be many errors. I will appreciate any advice.

https://drive.google.com/file/d/0Bx8l00 ... sp=sharing

[alvin]

I found several bugs in your C code and after correcting, it seems to work:
https://drive.google.com/file/d/0B6XhJJ ... sp=sharing

I am compiling with the current version of z88dk with:
zcc +msx -v -subtype=rom -create-app -m --list -O2 -pragma-define:CRT_MODEL=2 FallOfPrometheus.c graphics.asm -o FoP
(you'll notice I moved that bit of graphics data at the end of the .c file to a separate file "graphics.asm" -- adding asm code at global scope causes a lot of problems).

I was surprised that sccz80 let so many errors go without complaining. I ran an sdcc compile as it likes to complain and that identified a lot of errors:
zcc +msx -v -subtype=rom -create-app -m --list -compiler=sdcc -pragma-define:CRT_MODEL=2 FallOfPrometheus.c graphics.asm -o FoP

Unfortunately sdcc crashes during the compile so you can't use it to build the game as is. I am not sure what the problem might be.

I'll post a bit later with details of some of the bugs.

[alvin]

There were a lot of instances like this:

Code: Select all

Tpersonaje jugador;
unsigned int celda_x1 = (jugador->posx + error_permitido)  >> 3;

"jugador" is a structure, not a pointer to one, so "jugador->posx" should be "jugador.posx". I have a feeling you changed from pointer to structure at some point.

Code: Select all

unsigned char cambio_liquidos;
liquido->indice = *cambio_liquidos == MEDIUM_CAMBIO_LIQUIDO?1:0;

Maybe another change away from pointer but "*cambio_liquidos" should be "cambio_liquidos"

There were a few instances of functions used before they were declared. I added prototypes for a couple of them at the top of the file.

Code: Select all

poner_level_tiles(unsigned int posicion, unsigned char color)

In modern C you should never leave types unspecified. Eg, if there is no return value, make it void type. If the function takes no arguments, don't declare as in "void foo()" but "void foo(void)". If types are incompletely specified the compiler will be unable to do some error checking.

Code: Select all

Tpersonaje jugador;
if (!hay_colision_cuadrado(jugador, jugador.velx, 0))

A couple of calls expecting a pointer. "jugador" in the above should be "&jugador". Probably another example of not completing the change from pointer to struct. Neither sccz80 nor zsdcc can pass structures by value (fyi in case you didn't know) and since that is wasteful in speed and program size, most of the time you want to pass pointers anyway.

And a few other things of similar nature.


The way you've organized your header files is not how it's intended to be done in C (and unfortunately there are a lot of examples on 8-bit platforms where it's done completely wrong). The purpose of header files is to define a public interface for humans to refer to and to enforce typing by the compilers.

So the header should not contain any data or functions, it should only declare their existence in prototype and extern form.

Eg, for some foo.c file that exports two functions:

foo.h

Code: Select all

#ifndef FOO_H
#define FOO_H

extern int sum(int a, int b);
extern void calculate(int *a, unsigned int n);

#endif

The implementation "foo.c" would include all headers declaring things it uses as well as its own header. The compiler can then check the consistency of foo.h and foo.c to make sure everyone sees a correct foo.h.

foo.c

Code: Select all

#include <stdio.h>
#include "foo.h"

int sum(int a, int b)
{
   return a+b;
}

...

If you have global data in, say, globals.c put the declarations in globals.h and the actual definitions in globals.c.

globals.h

Code: Select all

#ifndef GLOBALS_H
#define GLOBALS_H

struct jamma
{
   int a;
   int b;
}

extern int g_sum;
extern struct jamma jamma1;

#endif

globals.c

Code: Select all

#include "globals.h"

int g_sum;
struct jamma jamma1;

Just some fyi


The output of my compile which may be a bit different from 1.99B since rom compiles with the classic lib was still new at that point:

-rw-r--r-- 1 alvin alvin 52153 Feb 24 17:14 FallOfPrometheus.c
-rw-r--r-- 1 alvin alvin 31963 Feb 24 16:34 FallOfPrometheus.h
-rw-r--r-- 1 alvin alvin 13507 Feb 24 17:16 FoP.bin
-rw-r--r-- 1 alvin alvin 47574 Feb 24 17:16 FoP.map
-rw-r--r-- 1 alvin alvin 32768 Feb 24 17:16 FoP.rom
-rw-r--r-- 1 alvin alvin 104 Feb 24 17:16 FoP_BSS.bin
-rw-r--r-- 1 alvin alvin 11617 Feb 24 17:16 FoP_DATA.bin
-rw-r--r-- 1 alvin alvin 478 Feb 24 16:03 graphics.asm
-rw-r--r-- 1 alvin alvin 53413 Jan 7 12:00 logomenu.h
-rw-r--r-- 1 alvin alvin 452 Feb 24 16:06 Makefile
-rw-r--r-- 1 alvin alvin 15637 Feb 23 12:06 tanatos_lv1.h
-rw-r--r-- 1 alvin alvin 10769 Feb 24 16:35 tileset_t.h

The data section is 11617 bytes and the bss section is 104 bytes so total ram usage is 11617+104=11721 bytes plus the stack. The rom cartridge portion is "FoP.bin" (13507 bytes) plus the compressed data section (3483 bytes stated during the compile).

Even though you've assigned that data to a rom segment with const, sccz80 is not currently assigning that to an rodata section. This is being fixed now: https://github.com/z88dk/z88dk/issues/81 . If all the data section items are moved to rom, your rom will occupy 13507+11617=25124 bytes so if your program becomes bigger you may want to juggle what goes into ram and what doesn't.

[eldeljar]

Hi Alvin, thank you very much for everything.

I will follow your advice and I will reorganize and correct the source code.

I downloaded the code you modified, but after compiling, the game starts, but the screen does not display correctly.

I am compiling with:

Code: Select all

zcc + msx -subtype = rom -create-app -m -list -O2 -pragma-define: CRT_MODEL = 2 FallOfPrometheus.c graphics.asm -o FoP

Do I have to compile with sdcc? Can you tell me how to install sdcc with z88dk?

[alvin]

>I downloaded the code you modified, but after compiling, the game starts, but the screen does not display correctly.

I updated the same zip with a screenshot so you can compare to what I see.

I noticed my last compile was using the -O2 flag (this is the default optimization level used during compiles; -O3 does some things that reduce program size and -O0 / -O1 can be used to lower optimization level to check if there is an error in the optimizer rules). I tried compiling again this morning with -O3 and -O0 and neither of these produces anything working. I'm thinking there may be some other bug in your program not related to syntax issues? I will have another look later on.

> Do I have to compile with sdcc? Can you tell me how to install sdcc with z88dk?

For windows and osx users, the sdcc binaries are included with z88dk. Linux users can build them according to these instructions:
https://www.z88dk.org/wiki/doku.php?id=temp:front#sdcc1

Unfortunately sdcc is crashing with a seg fault when compiling your program. I have seen this happen a handful of times and is a bug somewhere in sdcc. It could be sdcc is running out of space for some fixed size resource while compiling your program so I don't know if things might work if your program were split into smaller pieces. The move to separating data/functions out of .h files will reduce the amount that is compiled in each .c file.

You may also want to keep up with the current z88dk. This is a very active project and already since 1.99B there have been some changes:
https://www.z88dk.org/wiki/doku.php?id= ... stallation using the latest source at https://github.com/z88dk/z88dk might be easiest. The install instructions mention using the nightly source tarball but if you are comfortable with it, git makes it easier to stay up to date.

I'm compiling with the current code base.

[alvin]

sccz80 was just updated and I tried a quick compile to see if things are different.

Now I get screenshot2 in the same zip and we start on level 2. The main character can now move.

Are you depending on the bss section being zeroed prior to start? The classic compile is not doing that and it should.. I will open an issue now and fix that later today if no one else has.
https://github.com/z88dk/z88dk/issues/87

The new c lib was written with all these things in mind and the classic lib is catching up but I think it's very close to complete in terms of rom issues.

[eldeljar]

I installed the latest version nightly (2017-02-27 03:11 16M), it generates a 24K .bin, a "bss" file of 104 bytes and a "DATA" file of 9 bytes. If I run the game on the emulator, then it does not work for me.

So, for now, I will continue with version 1.99B. In any case, it still does not work: if I create a new function or uncomment the code of the function "poner_puerta", the game does not work.

I am currently compiling on Ubuntu 16 (64 bit), but I will try it on Windows to see if it is a problem with the operating system.

[alvin]

The program no longer works for me after the bss section initialization has been fixed and another bug was fixed. I plan on taking a closer look at it when I get a chance maybe tonight. The flakiness suggests there is something wrong with the program itself but I'd like to be sure. Maybe splitting up the program into its smaller logical pieces (you've already done that with headers but everything is currently included into one large piece) will allow sdcc to compile too - one thing that is really helpful about having two compilers on the go is being able to quickly determine if the problem is in the compiler or not.

[eldeljar]

Hello, I have divided the game into several files and I left it in the following link:

Https://drive.google.com/open?id=0Bx8l0 ... EVHeEwxRUE

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".

Possibly there is an error in the source code, but the compiler does not tell me, so I will try to compile with sdcc (when the installation works) to see if it gives me more information.

Thank you very much

[eldeljar]

Hello, I have divided the game into several files and I left it in the following link:

https://drive.google.com/file/d/0Bx8l00 ... sp=sharing

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".

Possibly there is an error in the source code, but the compiler does not tell me, so I will try to compile with sdcc (when the installation works) to see if it gives me more information.

Thank you very much

[eldeljar]

Sorry, the second link is the correct.

[alvin]

> 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.

[alvin]

Sorry this is the link to the updated zip (same link as earlier):
https://drive.google.com/file/d/0B6XhJJ ... sp=sharing

[alvin]

> 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.

This is a bug in sdcc, I've filed it now:
https://sourceforge.net/p/sdcc/bugs/2590/

We'll see if they fix it in a timely manner otherwise maybe we'll take a look at it.

[eldeljar]

Hi Alvin, I have seen that the reported error has been closed. I downloaded the latest version of the sdcc compiler and the latest version of z88dk (nightly) for linux, and I tried to compile the project but it gives me errors.

Some errors I have corrected by organizing the source code (https://drive.google.com/file/d/0Bx8l00 ... sp=sharing), but others do not know how to look at them, since they refer to a temporary asm file.

If I compile with sdcc with the latest version of windows z88dk (nightly), it compiles everything correctly (there are some warnings), but the game does not work. I guess this version does not have the latest version of sdcc.

Please, if you have any advice on what I can modify, please let me know.

Thank you very much

[alvin]

Hi eldeljar,

https://drive.google.com/file/d/0B6XhJJ ... sp=sharing

I didn't change anything except maybe the project file and I got rid of the pragma file which was unnecessary.

sccz80 compile:
zcc +msx -O3 -subtype=ROM -create-app -o FoP.bin @zproject.lst

sdcc compile (no optimization):
zcc +msx -vn -compiler=sdcc -subtype=rom -create-app -o FoP.bin @zproject.lst

Both are successful. The sccz80 compile looks the most complete; the sdcc compile doesn't print the background properly. I will look into why that it is (it could be undefined behaviour due to program bug or a problem with the library interface to sdcc). Do you see any possible bugs in the sccz80 version that could be corrected?