#1202 Z80 port broken

closed-fixed
Maarten Brock
z80 port (188)
5
2013-05-25
2006-09-26
Anonymous
No

I cannot get a working Z80 binary out of current sdcc.
Sorry, I don't now what's wrong. I test my programs in
an emulator, without debugger. All I see is that the
screen of the emulated system justs stays blank.
Since I don't really know the problem so far I tried to
find the change that caused it instead.
#4380 works, #4381 is broken.

Philipp

Discussion

  • Logged In: YES
    user_id=564030

    Since my programs fail so early it might be a linker
    problem. But it seems at least my crt0.obj is placed correctly.

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2006-09-27

    Logged In: YES
    user_id=888171

    Philipp,

    In #4381 I moved the z80 linker sources from sdcc/link/z80
    to sdcc/as/link/z80 in the source tree. Assuming you use
    the sources you need to reconfigure and rebuild SDCC.

    make distclean
    ./configure
    make
    make install

    Hope this helps,
    Maarten

     
  • Logged In: YES
    user_id=564030

    When I tried the different revisions I uninstalled the old
    one unsing
    make uninstall
    deleted the source tree and did a fresh checkout from
    subversion,
    ./configure
    make install

    I did this for each revision I tried.

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2006-09-27

    Logged In: YES
    user_id=888171

    I did not look good enough. I moved the linker in #4377.
    In #4381 I merged some files with the other ports. Btw.
    #4381 failed regression tests when the VPATH option was
    used. This was fixed in #4382.

    Do you get any error messages?
    Can you compare the output of the two versions?

    Maarten

     
  • Logged In: YES
    user_id=564030

    I found the problem:
    The linker puts global variables into ROM instead of RAM.

    Here's part of my crt0.map file:
    AREA _DATA
    RADIX HEX
    BASE 7000
    SIZE 01C4
    ATTRIB REL CON
    GLOBALS
    _cloudrow EEFA
    _groundrows EF8A
    _step F0AB
    _skill F0AC
    _lives_remaining F0AD
    _score F0AE
    _two_players F0B0
    _second_player F0B1
    _cv_nmi_handler F0B4
    _cv_vdpstat F0B6
    _cv_nmi_indicator F0B7
    _cv_vdpreg F0B8
    _cv_spinners F0BA

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2006-09-27

    Logged In: YES
    user_id=888171

    Philipp,

    Please help me a little. Does this mean you placed area
    _DATA at 0x7000-0x71C4 but that the variables ended up at
    0xEEFA-0xF0BE ? What command line options did you use when
    compiling and linking?

    Maarten

     
  • Logged In: YES
    user_id=564030

    For linking I use
    -mz80 --no-std-crt0 --code-loc 0x8100 --data-loc 0x7000
    For compiling
    -mz80 -c "-I../colecovision lib/include/" --std-c99

    The program compiles and links without errors. The only
    warning I get is from a manually placed #warning.

    I have 32K ROM at 0x8000 (custom crt0.o there, sdcc
    generated stuff starts at 0x8100), 1K RAM at 0x7000

    >Does this mean you placed area
    >_DATA at 0x7000-0x71C4 but that the variables
    >ended up at 0xEEFA-0xF0BE ?
    Yes.
    I noticed this by compiling with #4380 and #4381 to binary.
    Disassembling and diff. The I looked at the crt0.map file.

     
  • Maarten Brock
    Maarten Brock
    2006-09-27

    Logged In: YES
    user_id=888171

    A quick compile with similar options generated correct
    results. What are the special contents of your crt0?
    Esp. .org and .area are interesting.

     
  • Logged In: YES
    user_id=564030

    Hmm, I forgot to log in when creating the bug report so I
    cannot attach files.

    (I just verified again that it's a linker problem: programs
    compiled with new sdcc, linked with old one work ok)

    Here's my crt0.s:
    ; crt0.s for Colecovision cart

    .module crt0
    .globl _main
    .globl _cv_init
    .globl _cv_nmi

    .area _HEADER(ABS)

    .org 0x8000

    .db 0x55, 0xaa ; Title screen and 12 second delay - swap
    0x55 and 0xaa not to skip it.

    .dw 0 ; sprite table stuff? - rarely used by the
    BIOS as a pointer

    .dw 0 ; unknown - rarely used as a pointer to a
    single byte of RAM by the BIOS.

    .dw 0 ; unknown - frequently used in BIOS routines
    as a pointer to a memory location (data is both written to
    and read from there, at least 124 bytes are used - maybe
    this is where the bios routines store most of their data,
    though with the common value of 0 this would be in the BIOS
    ROM itself - strange).

    .dw 0 ; unknown - rarely used as a pointer to a
    single byte of RAM by the BIOS.

    .dw start ; where to start execution of program.

    ei ; RST 0x08

    reti

    ei ; RST 0x10

    reti

    ei ; RST 0x18

    reti

    ei ; RST 0x20

    reti

    ei ; RST 0x28

    reti

    ei ; RST 0x30

    reti

    ei ; RST 0x38 - spinner interrupt

    reti
    jp nmi ; NMI

    nop
    .ascii " / / NOT"

    start:

    ld sp, #0x73ff ; Set stack pointer to top of memory.

    call gsinit ; Initialize global variables.

    call _cv_init ; Initialize Colecovision specific stuff.

    call _main
    rst 0x0 ; Restart when main() returns.

    ;; Ordering of segments for the linker.
    .area _HOME
    .area _CODE
    .area _GSINIT
    .area _GSFINAL

    .area _DATA
    .area _BSS
    .area _HEAP

    .area _CODE

    nmi: push af
    push bc
    push de
    push hl
    push ix
    push iy
    call _cv_nmi
    pop iy
    pop ix
    pop hl
    pop de
    pop bc
    pop af
    retn

    .area _GSINIT
    gsinit::

    .area _GSFINAL

    ret

     
  • Logged In: YES
    user_id=564030

    To reproduce the bug, assemble the crt0.s to crt0.o in my
    last message using
    as-z80 -plosgff
    compile the main.c below using
    sdcc -c -mz80 main.c
    link everything using
    sdcc -mz80 --data-loc 0x7000 --code-loc 0x800 --no-std-crt0
    crt0.o main.o

    As you can see in the crt0.map created by the linker the
    global variable x from main.c is placed in code space at
    0x8051 instead of data space at 0x7000

    main.c:

    int x;

    void main(void)
    {
    }

     
  • Logged In: YES
    user_id=564030

    That should have been --code-loc 0x8000 in the last message,
    not 0x800

     
  • Maarten Brock
    Maarten Brock
    2006-10-02

    • assigned_to: nobody --> maartenbrock
     
  • Maarten Brock
    Maarten Brock
    2006-10-02

    Logged In: YES
    user_id=888171

    I guessed as much. And I was able to reproduce the
    problem. I've taken on this bug as I have probably caused
    it, but am unsure when I'll have some time again to
    investigate.

     
  • Maarten Brock
    Maarten Brock
    2006-10-02

    • milestone: --> fixed
    • status: open --> closed-fixed
     
  • Maarten Brock
    Maarten Brock
    2006-10-02

    Logged In: YES
    user_id=888171

    Found some time and that the problem was in lkarea.c. Kind
    of reverted back to the previous code in SDCC 2.6.1 #4399.