Z88dk: [mz2500][rand()] rand() outputs always zero (in my game)

[Fabrizio-Caruso]

I am having a weird issue.
In my game rand() always outputs zero.
I compile my game with:

mz2500_tiny_buffered:
    $(Z88DK_PATH)$(MYZ88DK) +mz2500 \
    -SO3 \
    -compiler=sdcc \
...
    -vn \
    -lndos \
    -pragma-include:$(CFG_PATH)/z88dk/zpragma_clib.inc \
    $(TINY_FILES) \
    $(CROSS_LIB_PATH)/display/alt_print/memory_mapped_alt_print.c \
    -create-app 

I get the same issue with SCCZ80.

This is not reproducible in a simple test because the issue is not present in a trivial example.

Could this come from the pragmas used?

// It next exits
#pragma-define:CLIB_EXIT_STACK_SIZE=0
// Do not initialize BSS
#pragma-define:CRT_INITIALIZE_BSS=0
// move the stack to available memory
#pragma output REGISTER_SP = -1      // must be placed somewhere in the 16k ram
// halt program on exit, no need to play well with basic
#pragma output CRT_ON_EXIT = 0x10001
// eliminate the malloc heap
#pragma output CLIB_MALLOC_HEAP_SIZE = 0
// eliminate the stdio heap (no files can be opened)
#pragma output CLIB_STDIO_HEAP_SIZE = 0
// eliminate unused printf converters
#pragma printf = "%0u"    // placed used converters here, empty string if none

[zx70]

is it happening on all the targets ?
if it happens only on the mz2500 then it could be the SEED internal variable not writable (e.g. pointing to a ROM zone rather than in RAM).. can you paste the few code lines around your rand() call?

[Fabrizio-Caruso]

@zx70 this only happens under some circumstances, which seem unrelated to the problem.
It may be some sort of overflow in memory. I really don't know.

rand() works fine (range 0000-0x7fff) on the mz2500 if you test just test rand().

I am going to test the cpm target with the very same code and see if it behaves strangely.

This is the function that mis-behaves:

#if defined(__NCURSES__) || defined(__GCC_BUFFERED__)
    #define GHOST_RANDOM_CONDITION ((rand()&0x7fff)>slowDown)
#else
    #define GHOST_RANDOM_CONDITION (rand()>slowDown)
#endif
void chaseCharacter(unsigned short slowDown)    
{
    unsigned char i;

    for(i=0;i<GHOSTS_NUMBER;++i)
    {
                        if((ghosts[i]._status) && GHOST_RANDOM_CONDITION)   
            {
                deleteGhost(&ghosts[i]);
                moveTowardCharacter(&ghosts[i]);    
            }
    }
}

[Fabrizio-Caruso]

@zx70
It only happens on the mz2500 target.
Could this be related to the size of the binary and/or disk image?

OK: cpm

test:
    $(Z88DK_PATH)$(MYZ88DK) +cpm \
    -SO3 \
    -compiler=sdcc \
    -DFORCE_XSIZE=16 \
    -DFORXE_YSIZE=16 \
    -DFORCE_GHOSTS_NUMBER=6 \
    -DFORCE_BOMBS_NUMBER=2 \
    -vn \
    -DNO_COLOR \
    -DTINY_GAME \
    -DNO_BLINKING \
    -DNO_CONTROL_INSTRUCTIONS \
    -DNO_DEAD_GHOSTS \
    -DNO_SLEEP \
    -DNO_INITIAL_SCREEN \
    -DNO_SET_SCREEN_COLORS \
    -lndos \
    -DBUFFERED -DNO_INIT_GRAPHICS \
    -DFORCE_NARROW \
    -DNO_STATS \
    -DALT_PRINT \
    -DALT_CLEAR_SCREEN \
    -DSTDLIB \
    -DNO_WAIT \
    -DBUFFRED \
    -DTURN_BASED \
    -pragma-include:$(CFG_PATH)/z88dk/zpragma_clib.inc \
    $(CROSS_LIB_PATH)/display/alt_print/memory_mapped_alt_print.c \
    $(TINY_FILES) \
    -create-app
    rm a.bin
    mv A.COM $(BUILD_PATH)/TINY_CPM_TINY_BUFFERED.COM

KO mz2500:

mz2500_tiny_buffered:
    $(Z88DK_PATH)$(MYZ88DK) +mz2500 \
    -SO3 \
    -compiler=sdcc \
    -DFORCE_XSIZE=16 \
    -DFORXE_YSIZE=16 \
    -DFORCE_GHOSTS_NUMBER=6 \
    -DFORCE_BOMBS_NUMBER=2 \
    -D__MZ2500__ \
    -vn \
    -DNO_COLOR \
    -DTINY_GAME \
    -DNO_BLINKING \
    -DNO_CONTROL_INSTRUCTIONS \
    -DNO_DEAD_GHOSTS \
    -DNO_SLEEP \
    -DNO_INITIAL_SCREEN \
    -DNO_SET_SCREEN_COLORS \
    -lndos \
    -DBUFFERED -DNO_INIT_GRAPHICS \
    -DFORCE_NARROW \
    -DNO_STATS \
    -DALT_PRINT \
    -DALT_CLEAR_SCREEN \
    -DSTDLIB \
    -DNO_WAIT \
    -DBUFFRED \
    -DTURN_BASED \
    -pragma-include:$(CFG_PATH)/z88dk/zpragma_clib.inc \
    $(TINY_FILES) \
    $(CROSS_LIB_PATH)/display/alt_print/memory_mapped_alt_print.c \
    -create-app 
    mv a.2D $(BUILD_PATH)/TINY_mz2500_buffered.2D
    rm a.bin

[suborb]

@Fabrizio-Caruso can you try again after the next nightly? Hopefully being able to load larger programs has made this issue go away.

[Fabrizio-Caruso]

@suborb, sure! I am the tester! That is my self-appointed role! :-P

[Fabrizio-Caruso]

@suborb I can confirm that indeed it has fixed this issue!

[zx70]

Wonderful :)
It's probably very tricky to make it right but a warning in case of overflows in the BSS or DATA space could be nice to have.