Problem generating MSX ROM
If you update using the latest source tarball, you'll also have to recompile everything (ie build again as in https://www.z88dk.org/wiki/doku.php?id= ... inux_unix) to update the z88dk binaries and z80 libraries.
The version of zsdcc I am using is #9852 (zsdcc -v). This one or later will contain all the fixes.
The version of zsdcc I am using is #9852 (zsdcc -v). This one or later will contain all the fixes.
Hi, I'm trying out the latest z88dk version of linux and windows, and both compile the source code correctly.
However, loading the rom file into an emulator (openMSX and blueMSX) does not work.
If I comment the source code of some function (eg "pantalla1" or "poner_puerta") and compile with z88dk version 199B:
, the source code compiles and the rom works (correct rom in https://drive.google.com/file/d/0Bx8l00 ... sp=sharing).
If I delete the "-pragma-define:CRT_MODEL=2" option, compile but the rom does not work for me.
However, with the latest version of z88dk (every time I download it I compile it) it does not work for me in either case. I have noticed that the compression is different in both versions.
Finally, to compile with sdcc I use the z88dk version for windows, and the version is #9852. In this version it compiles, but the rom does not work. Many warnings come from constant variables.
The next thing I'm going to do is to change the access pointers to array positions, in case I have any pointer errors. I also have doubts if the MSX libraries of z88dk work correctly so I will also review them.
I can not think of anything else to prove.
However, loading the rom file into an emulator (openMSX and blueMSX) does not work.
If I comment the source code of some function (eg "pantalla1" or "poner_puerta") and compile with z88dk version 199B:
Code: Select all
zcc + msx -O3 -subtype = rom -create-app -pragma-define:CRT_MODEL=2 -o FallOfPrometheus .bin @ zproject.lst
If I delete the "-pragma-define:CRT_MODEL=2" option, compile but the rom does not work for me.
However, with the latest version of z88dk (every time I download it I compile it) it does not work for me in either case. I have noticed that the compression is different in both versions.
Finally, to compile with sdcc I use the z88dk version for windows, and the version is #9852. In this version it compiles, but the rom does not work. Many warnings come from constant variables.
The next thing I'm going to do is to change the access pointers to array positions, in case I have any pointer errors. I also have doubts if the MSX libraries of z88dk work correctly so I will also review them.
I can not think of anything else to prove.
This is the current source code built by 1.99B? This makes it easier to look into. There have been many changes in the last couple of months so it is possible something has gone wrong. I wasn't sure if there was a problem in your code or someplace else.eldeljar wrote:If I comment the source code of some function (eg "pantalla1" or "poner_puerta") and compile with z88dk version 199B:
, the source code compiles and the rom works (correct rom in https://drive.google.com/file/d/0Bx8l00 ... sp=sharing).Code: Select all
zcc + msx -O3 -subtype = rom -create-app -pragma-define:CRT_MODEL=2 -o FallOfPrometheus .bin @zproject.lst
We have an open issue concerning your program and CRT_MODEL=2 (https://github.com/z88dk/z88dk/issues/92). We couldn't see anything wrong with the decompression but the CRT_MODEL=1 (uncompressed) and CRT_MODEL=2 (compressed) don't behave the same which should not be the case.If I delete the "-pragma-define:CRT_MODEL=2" option, compile but the rom does not work for me.
With the current z88dk, a functioning ROM is built with CRT_MODEL=1 (the default). But it's bugged in comparison to 1.99B. Now that I know the problem has happened since 1.99B we don't have to look at your source code as a potential problem.
Yes sdcc is a complainer which is useful for tracking down bugs. All of the warnings are legitimate but most are not errors. I think there were a couple (not about const) that deserve looking at to make sure they are not errors too.However, with the latest version of z88dk (every time I download it I compile it) it does not work for me in either case. I have noticed that the compression is different in both versions.
Finally, to compile with sdcc I use the z88dk version for windows, and the version is #9852. In this version it compiles, but the rom does not work. Many warnings come from constant variables.
If 1.99B is compiling the current source to that working .ROM, I can focus on that.I can not think of anything else to prove.
Yes, the ROM of the previous post is compiled with version 1.99B, with the option "-pragma-define: CRT_MODEL = 2" and with the commented source code of the functions "pantalla1" (pantalla.c) and "poner_puerta" (tileset_t.c).alvin wrote:This is the current source code built by 1.99B? This makes it easier to look into. There have been many changes in the last couple of months so it is possible something has gone wrong. I wasn't sure if there was a problem in your code or someplace else.eldeljar wrote:If I comment the source code of some function (eg "pantalla1" or "poner_puerta") and compile with z88dk version 199B:
, the source code compiles and the rom works (correct rom in https://drive.google.com/file/d/0Bx8l00 ... sp=sharing).Code: Select all
zcc + msx -O3 -subtype = rom -create-app -pragma-define:CRT_MODEL=2 -o FallOfPrometheus .bin @zproject.lst
Thank you very much
It's something to do with the "const" which I am looking at now.
I can successfully compile with the current z88dk build if "const" goes away:
zcc +msx -O3 -subtype=ROM -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
(that's a blank after "const" to make it a blank in source code).
I can successfully compile with the current z88dk build if "const" goes away:
zcc +msx -O3 -subtype=ROM -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
(that's a blank after "const" to make it a blank in source code).
If I remove the constants the source code compiles and the rom works.
If I compile with "-DConst =" the result is as follows:
Otherwise:
Tested with the latest version for today's windows.
However, if I add a new function ("pantalla3" which is a duplicate of "pantalla1") and I compile with "-Dconst =" the source code compiles but the rom does not work.
I indicate if this data can help in any way.
Thank you very much for the help.
If I compile with "-DConst =" the result is as follows:
Code: Select all
FoP.bin -> 13K
FoP_BSS.bin -> 1K
FoP_DATA.bin -> 12K
File converted from 11569 to 3470 bytes! (Delta 2)
Code: Select all
FoP.bin -> 18K
FoP_BSS.bin -> 1K
FoP_DATA.bin -> 7K
File converted from 6321 to 792 bytes! (Delta 2)
However, if I add a new function ("pantalla3" which is a duplicate of "pantalla1") and I compile with "-Dconst =" the source code compiles but the rom does not work.
I indicate if this data can help in any way.
Thank you very much for the help.
I've been trying compiles again and they all seem to work with the -Dconst= to disable const even with all functions enabled:
zcc +msx -v -O3 -subtype=rom -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
The sdcc compiles also seem to work but they have slightly different behaviour for the fireballs. I will have to look into that to see if something is going on:
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node200000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
But looking at your code it looks like there are a lot of variables defined as const that cannot be const. For example, from pantallas.c:
So I think all the problems are down to these errors everywhere.
If you declare data as const as in "const Tobjeto lista_antorchas[3] = ..." that data gets placed into ROM. Trying to change values in ROM will not work which is why you can't do "objeto->posx = 2;". When the compile is done with "-Dconst=" we're getting rid of all the const keywords and "Tobjeto lista_antorchas[3] = ..." will then be placed in RAM where ""objeto->posx = 2;" will get the expected result.
zcc +msx -v -O3 -subtype=rom -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
The sdcc compiles also seem to work but they have slightly different behaviour for the fireballs. I will have to look into that to see if something is going on:
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node200000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
But looking at your code it looks like there are a lot of variables defined as const that cannot be const. For example, from pantallas.c:
Code: Select all
void pantalla1(unsigned char reiniciar_level)
{
Tobjeto *objeto = lista_antorchas; // globales.c: const Tobjeto lista_antorchas[3]
Tpersonaje *ciclope = lista_ciclopes; // globales.c: const Tpersonaje lista_ciclopes[3]
Ttile_movil *fireball = lista_fireballs; // globales.c: const Ttile_movil lista_fireballs[3]
pantalla_actual = pantalla_tanatos_lv1; // tanatos.c: const unsigned char pantalla_tanatos_lv1[768]
lista_tiles_actual = lista_tiles_t; // tileset_t.c: const unsigned char* lista_tiles_t[48]
lista_tiles_attr_actual = lista_tiles_t_attr; // tileset_t.c: const unsigned char* lista_tiles_t_attr[48]
...
objeto->posx = 2; // can't do this - lista_antorchas is const
objeto->posy = 2; // can't do this - lista_antorchas is const
...
objeto->estado = (unsigned char) 0; // can't do this
...
objeto++; // ok - objeto itself is a ram variable
...
ciclope->posx = 64; // can't do this - lista_ciclopes is const
ciclope->posy = 112; // can't do this
ciclope->dirx = 0; // can't do this
ciclope->diry = 1; // can't do this
If you declare data as const as in "const Tobjeto lista_antorchas[3] = ..." that data gets placed into ROM. Trying to change values in ROM will not work which is why you can't do "objeto->posx = 2;". When the compile is done with "-Dconst=" we're getting rid of all the const keywords and "Tobjeto lista_antorchas[3] = ..." will then be placed in RAM where ""objeto->posx = 2;" will get the expected result.
Hello Alvin, I'm modifying the source code to try to find the problem. I have corrected what you have indicated.
On the other hand, if I delete const in the source code and generate the rom, the rom works. However, if I add new screens and functions (to simulate that the game has 10 screens), the rom does not work, although I use -Dconst.
I guess the reason is that all the data (tiles, sprites, etc.) are in RAM and exceed 16Kb. Therefore, I need to have data in ROM.
I am testing what data I can have in ROM and what in RAM and the rom does not fail.
Finally, I thought that when using pointers I could modify constant values stored in ROM. I'm correcting it.
Thank you very much for the help
On the other hand, if I delete const in the source code and generate the rom, the rom works. However, if I add new screens and functions (to simulate that the game has 10 screens), the rom does not work, although I use -Dconst.
I guess the reason is that all the data (tiles, sprites, etc.) are in RAM and exceed 16Kb. Therefore, I need to have data in ROM.
I am testing what data I can have in ROM and what in RAM and the rom does not fail.
Finally, I thought that when using pointers I could modify constant values stored in ROM. I'm correcting it.
Thank you very much for the help
I'm still looking into this too. There is something going on here that I don't understand yet.
With SDCC COMPILES I seem to be getting consistently correct results with the compressed rom model (that is, the same result no matter the optimization settings which might imply that the generated code is correct). You may want to try compiles with sdcc to see if things work right.
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst= --fsigned-char
(lowish 10000 allocs number chosen so that I don't become an old man waiting for compiles to finish). The "--fsigned-char" is important because of the function "unsigned char hay_colision_tiles(Ttile_movil *objeto, char inc)" in tileset_t.c. Without it you will get a compiler warning about numbers being out of range that is correctly identifying a bug. sdcc treats "char" as unsigned by default because that leads to better z80 code but in this program you need it to be signed so the extra flag must be added. The C standard lets the implementation decide if char is signed or not so it's better if you take that decision by using "signed char" or "unsigned char" in your code.
However if I change to uncompressed rom model:
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst= --fsigned-char
The background tiles are not properly initialized. The game still seems to work with the player being able to move and whatnot but the screen graphics is garbage. I can't explain this yet. The only thing I can think of is the crt is not initializing ram from the stored rom data which I will look into.
With SCCZ80 compiles the same uninitialized data problem happens with the uncompressed rom model. That's not surprising because the same backend is handling that for both compilers.
With the compressed rom model, sccz80 is producing something that works but is not quite right:
zcc +msx -v -O3 -subtype=rom -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
In comparison to the sdcc compile, the fireball goes through the key in the bottom right. I'd like to look into this -- can you tell me what function determines whether that fireball stops at the key?
If I compile at lower optimization settings (-O2, -O1, -O0) things become worse. This tells me that the compiler itself has a bug and O3 is actually inadvertently partially fixing it.
With SDCC COMPILES I seem to be getting consistently correct results with the compressed rom model (that is, the same result no matter the optimization settings which might imply that the generated code is correct). You may want to try compiles with sdcc to see if things work right.
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst= --fsigned-char
(lowish 10000 allocs number chosen so that I don't become an old man waiting for compiles to finish). The "--fsigned-char" is important because of the function "unsigned char hay_colision_tiles(Ttile_movil *objeto, char inc)" in tileset_t.c. Without it you will get a compiler warning about numbers being out of range that is correctly identifying a bug. sdcc treats "char" as unsigned by default because that leads to better z80 code but in this program you need it to be signed so the extra flag must be added. The C standard lets the implementation decide if char is signed or not so it's better if you take that decision by using "signed char" or "unsigned char" in your code.
However if I change to uncompressed rom model:
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst= --fsigned-char
The background tiles are not properly initialized. The game still seems to work with the player being able to move and whatnot but the screen graphics is garbage. I can't explain this yet. The only thing I can think of is the crt is not initializing ram from the stored rom data which I will look into.
With SCCZ80 compiles the same uninitialized data problem happens with the uncompressed rom model. That's not surprising because the same backend is handling that for both compilers.
With the compressed rom model, sccz80 is producing something that works but is not quite right:
zcc +msx -v -O3 -subtype=rom -create-app -pragma-define:CRT_MODEL=2 -o FoP @zproject.lst -Dconst=
In comparison to the sdcc compile, the fireball goes through the key in the bottom right. I'd like to look into this -- can you tell me what function determines whether that fireball stops at the key?
If I compile at lower optimization settings (-O2, -O1, -O0) things become worse. This tells me that the compiler itself has a bug and O3 is actually inadvertently partially fixing it.
There's no editing here so I'll just have to add more:
If you use github, the fix to sdcc's peephole set is available with an update. There are no changes to the binaries. The original issue: https://github.com/z88dk/z88dk/issues/146
It's highly unlikely that this specific bug will affect your program but there's always a small chance.
That's pragma-define:CRT_MODEL=1 to select the uncompressed rom model as correct above.However if I change to uncompressed rom model:
zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=1 -o FoP @zproject.lst -Dconst= --fsigned-char
If you use github, the fix to sdcc's peephole set is available with an update. There are no changes to the binaries. The original issue: https://github.com/z88dk/z88dk/issues/146
It's highly unlikely that this specific bug will affect your program but there's always a small chance.
Hello Alvin
If (* (current_list + object-> tile_actual + inc))! = 0)
The correct code is:
If (* (current_list + * (current_list + (object-> tile_actual + inc)))! = 0)
I'm checking if I have other similar cases.
As you indicate, with CRT_MODEL = 2, the game works perfectly (until I add new functions and tilemaps). However, with CRT_MODEL = 1 the game works but the map is not displayed correctly.
One thing I've seen is that when generating the rom with CRT_MODEL = 2, the .bin file is 13Kb, but when I generate it with CRT_MODEL = 1 it's 12Kb. If I generate with CRT_MODEL = 2 and without -Dconst =, the size is 17Kb. I'm not sure why, considering that CRT_MODEL = 2 is the rom compressed model.
Thank you very much
In the "hay_colision_tiles" function, the line in sdcc does not work properly:alvin wrote:In comparison to the sdcc compile, the fireball goes through the key in the bottom right. I would like to look into this - can you tell me what it means if fireball stops at the key?
If (* (current_list + object-> tile_actual + inc))! = 0)
The correct code is:
If (* (current_list + * (current_list + (object-> tile_actual + inc)))! = 0)
I'm checking if I have other similar cases.
As you indicate, with CRT_MODEL = 2, the game works perfectly (until I add new functions and tilemaps). However, with CRT_MODEL = 1 the game works but the map is not displayed correctly.
One thing I've seen is that when generating the rom with CRT_MODEL = 2, the .bin file is 13Kb, but when I generate it with CRT_MODEL = 1 it's 12Kb. If I generate with CRT_MODEL = 2 and without -Dconst =, the size is 17Kb. I'm not sure why, considering that CRT_MODEL = 2 is the rom compressed model.
Thank you very much
This has been reported as a bug at sdcc:eldeljar wrote:In the "hay_colision_tiles" function, the line in sdcc does not work properly:
If (* (current_list + object-> tile_actual + inc))! = 0)
https://sourceforge.net/p/sdcc/bugs/2601/
The compressed ROM model versus uncompressed ROM model discrepancy has been solved too:
https://github.com/z88dk/z88dk/issues/92
https://github.com/z88dk/z88dk/issues/92
This bug has been fixed in sdcc #9880.This has been reported as a bug at sdcc:
https://sourceforge.net/p/sdcc/bugs/2601/
I've updated the windows binary to this version here:
https://github.com/z88dk/z88dk/blob/mas ... _patch.zip
If you're using windows you can replace the zsdcc in z88dk/bin with this.
I'm not sure when the win32 and OSX binaries will be updated in the nightly build as we're heading toward a new release soon.
Anyway I think these two items clear up any compiler related issues with your program!
Hi, thank you very much for everything. Right now everything is working properly (in Windows versi?n). I have tried the following commands:
- Without compression:
If I do not use the "--fsigned-char" option, then the game compiles but collisions do not work correctly. I think there is an error in the source code.
Again, thank you very much for the help.
- Without compression:
- With compression:zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=1 -o FoP.bin @zproject.lst --fsigned-char
In both cases without the option "-Dconst =", and it works correctly.zcc +msx -v -subtype=rom -compiler=sdcc -SO3 --max-allocs-per-node10000 --reserve-regs-iy -create-app -pragma-define:CRT_MODEL=2 -o FoP.bin @zproject.lst --fsigned-char
If I do not use the "--fsigned-char" option, then the game compiles but collisions do not work correctly. I think there is an error in the source code.
Again, thank you very much for the help.
I'm glad to hear we finally figured out what was going on. It took a while but we got thereeldeljar wrote:Hi, thank you very much for everything. Right now everything is working properly (in Windows versi?n).
No, no errors in your source code. This is expected.If I do not use the "--fsigned-char" option, then the game compiles but collisions do not work correctly. I think there is an error in the source code.
You have some function parameters declared as "char" which you are expecting to be "signed char".
zsdcc will compile assuming all "char" are unsigned so you will get incorrect behaviour unless you tell zsdcc to make "char" into "signed char" with the "--fsigned-char" flag.
sccz80 makes "char" a "signed char" so there are no complications with sccz80.
The C standard allows the compiler to choose whether "char" is signed or not. zsdcc chooses not because that leads to better code. It's a good idea to make a conscious decision in your code to used "signed char" or "unsigned char" and never use "char" to avoid surprises like this. With the z80, always try to use unsigned types where it's possible as it leads to better generated code.