Menu

Wrong variable addresses? I'm probably doing some stupid...

Rink
2014-10-23
2014-10-24
  • Rink

    Rink - 2014-10-23

    Hi there,

    I'm trying to get started with sdcc, using it to compile for the z80. However, I've run into a problem straight away.

    If I compile:
    unsigned char *TEXT_VRAM = 0x3000;
    int main()
    {
    TEXT_VRAM[0] = 0x88;
    return 0;
    }

    With the command line:
    sdcc -mz80 --no-std-crt0 --code-loc 0x0000 --data-loc 0x8000 --stack-loc 0xFFFE --out-fmt-s19 Test.c

    Then the resulting files show that the variable TEXT_RAM is at address 0x8000. The assembly language code also uses 0x8000 to access the data. All sounds fine, except at 0x8000 there are two padding bytes. The actual data for TEXT_RAM doesn't start until 0x8002.

    This happens whether I compile to an Intel hex file and use hex2bin, or to a S19 file and use srec2bin.

    Anyone know why this would be? Many thanks.

     
  • Philipp Klaus Krause

    When I compile that using sdcc -mz80 --code-loc 0x0000 --data-loc 0x8000 z80.c, I get the expected result:

    TEXT_RAM is at address 0x8000.
    The data for TEXT_RAM is in the _INITIALIZER section at 0x13. The startup code in crt0.o copies the it from there to 0x8000.

    When you use --no-std-crt0 you need to supply a custom crt0, that provides the ordering of the areas, does some initialization (depends on your hardware) and initializes memory (including copying _INITIALIZER to _INITIALIZED). See the crt0.s from sdcc in sdcc/device/lib/z80 and the crt0.s from the libcv library (http://www.colecovision.eu/ColecoVision/development/libcv.shtml) for examples.

    Philipp

     
  • Rink

    Rink - 2014-10-24

    Aaaaahhhh. Thank you Philipp - I didn't realise crt0 did that.

    You're a star.

     
  • Rink

    Rink - 2014-10-24

    Oh, I meant to add:
    Thank you for linking me to your ColecoVision library. That's very helpful, and also very cool.

    All the best.

     

Log in to post a comment.

MongoDB Logo MongoDB