Problem generating MSX ROM

alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

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.
eldeljar
Member
Posts: 33
Joined: Sun Feb 12, 2017 6:04 pm

Post by eldeljar »

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:

Code: Select all

zcc + msx -O3 -subtype = rom -create-app -pragma-define:CRT_MODEL=2 -o FallOfPrometheus .bin @ zproject.lst
, 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.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

eldeljar wrote: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
, the source code compiles and the rom works (correct rom in https://drive.google.com/file/d/0Bx8l00 ... sp=sharing).
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.

If I delete the "-pragma-define:CRT_MODEL=2" option, compile but the rom does not work for me.
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.

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.
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.
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.
I can not think of anything else to prove.
If 1.99B is compiling the current source to that working .ROM, I can focus on that.
eldeljar
Member
Posts: 33
Joined: Sun Feb 12, 2017 6:04 pm

Post by eldeljar »

alvin wrote:
eldeljar wrote: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
, the source code compiles and the rom works (correct rom in https://drive.google.com/file/d/0Bx8l00 ... sp=sharing).
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.
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).

Thank you very much
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

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).
eldeljar
Member
Posts: 33
Joined: Sun Feb 12, 2017 6:04 pm

Post by eldeljar »

If I remove the constants the source code compiles and the rom works.
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)
Otherwise:

Code: Select all

FoP.bin -> 18K
FoP_BSS.bin -> 1K
FoP_DATA.bin -> 7K
File converted from 6321 to 792 bytes! (Delta 2)
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.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

Ok thanks eldeljar. I will have another go at this today. I am thinking some of those pointers declared as const are not const so that the program is attempting to write into the ROM?
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

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:

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
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.
eldeljar
Member
Posts: 33
Joined: Sun Feb 12, 2017 6:04 pm

Post by eldeljar »

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
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

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.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

There was a bugfix in sdcc's peephole rules last night but it won't show up until the next nightly build in about 8.5 hours. If the sdcc compile does not seem to work, try again after an update tomorrow.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

There's no editing here so I'll just have to add more:
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
That's pragma-define:CRT_MODEL=1 to select the uncompressed rom model as correct above.


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.
eldeljar
Member
Posts: 33
Joined: Sun Feb 12, 2017 6:04 pm

Post by eldeljar »

Hello Alvin
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?
In the "hay_colision_tiles" function, the line in sdcc does not work properly:

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
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

eldeljar wrote:In the "hay_colision_tiles" function, the line in sdcc does not work properly:

If (* (current_list + object-> tile_actual + inc))! = 0)
This has been reported as a bug at sdcc:
https://sourceforge.net/p/sdcc/bugs/2601/
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

The compressed ROM model versus uncompressed ROM model discrepancy has been solved too:
https://github.com/z88dk/z88dk/issues/92
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

This has been reported as a bug at sdcc:
https://sourceforge.net/p/sdcc/bugs/2601/
This bug has been fixed in sdcc #9880.

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!
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

I've updated the binaries so the 20170426 nightly will have the fixes.
eldeljar
Member
Posts: 33
Joined: Sun Feb 12, 2017 6:04 pm

Post by eldeljar »

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:
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
- With compression:
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
In both cases without the option "-Dconst =", and it works correctly.

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.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

eldeljar wrote:Hi, thank you very much for everything. Right now everything is working properly (in Windows versi?n).
I'm glad to hear we finally figured out what was going on. It took a while but we got there :)
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.
No, no errors in your source code. This is expected.

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