Crash while calling DIAMOND GOS from CC65.

tschak909 · November 17, 2022

Working on CC65 bindings for Diamond GOS...

Having an interesting crash while calling DIAMOND ($8E00) from CC65, I'm not sure what's happening?

Am just currently trying to call INIT, and EXIT, right after each other.

-Thom

HELLO.APP

TGB1718 · November 17, 2022

if I remember correctly cc65 uses memory locations high up, I'm no expert, but you can configure

your build script to change the locations it uses and reserve blocks of memory you want.

That may be your problem.

dmsc · November 17, 2022

Hi!

11 hours ago, tschak909 said:

Working on CC65 bindings for Diamond GOS...

Having an interesting crash while calling DIAMOND ($8E00) from CC65, I'm not sure what's happening?

Am just currently trying to call INIT, and EXIT, right after each other.

-Thom

HELLO.APP 551 B · 1 download

Reading through Diamond GOS documentation, it says that you can't use memory over $6000 when using graphics applications... But a little test shows that it leaves MEMTOP at $7C1F when loafing programs - this is $8000 minus the graphics 0 screen. So, one option could be to compile your program with __RESERVED_MEMORY__ set to 7199 ($1C1F).

Also, there is no documentation about which ZP locations are available to programs... I suppose that reserving from $80 to $97 should be enouhg?

Have Fun!

TGB1718 · November 17, 2022

48 minutes ago, dmsc said:

Also, there is no documentation about which ZP locations are available to programs... I suppose that reserving from $80 to $97 should be enouhg?

Having disassembled some cc65 programs, I think it uses at least $82 and $83 as a stack pointer to it's variable table,

there may be others, but not too sure.

tschak909 · November 17, 2022

1 hour ago, TGB1718 said:

Having disassembled some cc65 programs, I think it uses at least $82 and $83 as a stack pointer to it's variable table,

there may be others, but not too sure.

I scooted ZEROPAGE to $E5, so that it would be out of the way of the 16 registers. (I also tried just immediately scooting it past $97 first...) hm...

FEATURES {
    STARTADDRESS: default = $2000;
}
SYMBOLS {
    __EXEHDR__:          type = import;
    __AUTOSTART__:       type = import;  # force inclusion of autostart "trailer"
    __STACKSIZE__:       type = weak, value = $0800; # 2k stack
    __STARTADDRESS__:    type = export, value = %S;
    __RESERVED_MEMORY__: type = weak, value = $0000;
}
MEMORY {
    ZP:         file = "", define = yes, start = $00E5, size = $001A;

# file header, just $FFFF
    HEADER:     file = %O,               start = $0000, size = $0002;

# "main program" load chunk
    MAINHDR:    file = %O,               start = $0000, size = $0004;
    MAIN:       file = %O, define = yes, start = %S,    size = $BC20 - __STACKSIZE__ - __RESERVED_MEMORY__ - %S;
    TRAILER:    file = %O,               start = $0000, size = $0006;
}
SEGMENTS {
    ZEROPAGE:  load = ZP,         type = zp;
    EXTZP:     load = ZP,         type = zp,                optional = yes;
    EXEHDR:    load = HEADER,     type = ro;
    MAINHDR:   load = MAINHDR,    type = ro;
    STARTUP:   load = MAIN,       type = ro,  define = yes;
    LOWBSS:    load = MAIN,       type = rw,                optional = yes;  # not zero initialized
    LOWCODE:   load = MAIN,       type = ro,  define = yes, optional = yes;
    ONCE:      load = MAIN,       type = ro,                optional = yes;
    CODE:      load = MAIN,       type = ro,  define = yes;
    RODATA:    load = MAIN,       type = ro;
    DATA:      load = MAIN,       type = rw;
    INIT:      load = MAIN,       type = rw,                optional = yes;
    BSS:       load = MAIN,       type = bss, define = yes;
    AUTOSTRT:  load = TRAILER,    type = ro;
}
FEATURES {
    CONDES: type    = constructor,
            label   = __CONSTRUCTOR_TABLE__,
            count   = __CONSTRUCTOR_COUNT__,
            segment = ONCE;
    CONDES: type    = destructor,
            label   = __DESTRUCTOR_TABLE__,
            count   = __DESTRUCTOR_COUNT__,
            segment = RODATA;
    CONDES: type    = interruptor,
            label   = __INTERRUPTOR_TABLE__,
            count   = __INTERRUPTOR_COUNT__,
            segment = RODATA,
            import  = __CALLIRQ__;
}

Yes, reserving $80 to $97 should be enough.

-Thom

dmsc · November 17, 2022

Hi!

37 minutes ago, tschak909 said:

I scooted ZEROPAGE to $E5, so that it would be out of the way of the 16 registers. (I also tried just immediately scooting it past $97 first...) hm...

FEATURES {
    STARTADDRESS: default = $2000;
}
SYMBOLS {
    __EXEHDR__:          type = import;
    __AUTOSTART__:       type = import;  # force inclusion of autostart "trailer"
    __STACKSIZE__:       type = weak, value = $0800; # 2k stack
    __STARTADDRESS__:    type = export, value = %S;
    __RESERVED_MEMORY__: type = weak, value = $0000;
}
MEMORY {
    ZP:         file = "", define = yes, start = $00E5, size = $001A;

# file header, just $FFFF
    HEADER:     file = %O,               start = $0000, size = $0002;

# "main program" load chunk
    MAINHDR:    file = %O,               start = $0000, size = $0004;
    MAIN:       file = %O, define = yes, start = %S,    size = $BC20 - __STACKSIZE__ - __RESERVED_MEMORY__ - %S;
    TRAILER:    file = %O,               start = $0000, size = $0006;
}
SEGMENTS {
    ZEROPAGE:  load = ZP,         type = zp;
    EXTZP:     load = ZP,         type = zp,                optional = yes;
    EXEHDR:    load = HEADER,     type = ro;
    MAINHDR:   load = MAINHDR,    type = ro;
    STARTUP:   load = MAIN,       type = ro,  define = yes;
    LOWBSS:    load = MAIN,       type = rw,                optional = yes;  # not zero initialized
    LOWCODE:   load = MAIN,       type = ro,  define = yes, optional = yes;
    ONCE:      load = MAIN,       type = ro,                optional = yes;
    CODE:      load = MAIN,       type = ro,  define = yes;
    RODATA:    load = MAIN,       type = ro;
    DATA:      load = MAIN,       type = rw;
    INIT:      load = MAIN,       type = rw,                optional = yes;
    BSS:       load = MAIN,       type = bss, define = yes;
    AUTOSTRT:  load = TRAILER,    type = ro;
}
FEATURES {
    CONDES: type    = constructor,
            label   = __CONSTRUCTOR_TABLE__,
            count   = __CONSTRUCTOR_COUNT__,
            segment = ONCE;
    CONDES: type    = destructor,
            label   = __DESTRUCTOR_TABLE__,
            count   = __DESTRUCTOR_COUNT__,
            segment = RODATA;
    CONDES: type    = interruptor,
            label   = __INTERRUPTOR_TABLE__,
            count   = __INTERRUPTOR_COUNT__,
            segment = RODATA,
            import  = __CALLIRQ__;
}

Yes, reserving $80 to $97 should be enough.

-Thom

So, while you are there, just set __RESERVED_MEMORY__ to $1C1F should do the trick.

Have Fun!

tschak909 · November 17, 2022

@dmsc yup, setting reserved space to $2000 is sufficient. I can make a binding with this.

+MrFish · November 17, 2022

As a side note here...

I see something suspicious in your screenshot. That yellow color usually indicates a mismatch between the GOS 3.0 ROM and utility disk. When using the correct utility disk with GOS 3.0, your background should be pure white, like this (desktop artifacting color may vary... green, blue, etc.).

Use the utility disk and other software found here in order to maintain proper software compatibility for version 3.0.

Serious Computerist: Diamond GOS

Edited November 17, 2022 by MrFish

tschak909 · November 17, 2022

8 minutes ago, MrFish said:

As a side note here...

I see something suspicious in your screenshot. That yellow color usually indicates a mismatch between the GOS 3.0 ROM and utility disk. When using the correct utility disk with GOS 3.0, your background should be pure white, like this (desktop artifacting color may vary... green, blue, etc.).

Use the utility disk and other software found here in order to maintain proper software compatibility for version 3.0.

Serious Computerist: Diamond GOS

Am aware, I haven't made an OS configuration file yet. the default values for gos 3.0 are the ones on my screen. My only priority right now is to quickly put together a set of bindings, because I know how.

The background color by default, is supposed to be green, according to the development manual. Which makes sense, he was imitating GEM.

-Thom

+MrFish · November 17, 2022

2 minutes ago, tschak909 said:

Am aware, I haven't made an OS configuration file yet. the default values for gos 3.0 are the ones on my screen. My only priority right now is to quickly put together a set of bindings, because I know how.

OK

2 minutes ago, tschak909 said:

The background color by default, is supposed to be green, according to the development manual. Which makes sense, he was imitating GEM.

Sure ("GEM"/green), that's Alan's intention; but it depends on what system you're using, or emulating. I prefer XE artifacting, which is blue and orange for these graphics 8 colors. But, yeah, green will be on a lot of systems (XL I suppose); I wasn't concerned with that anyway, just the yellow; but I get your explanation.

Sign In

Crash while calling DIAMOND GOS from CC65.

Recommended Posts

tschak909

Link to comment

Share on other sites

TGB1718

Link to comment

Share on other sites

dmsc

Link to comment

Share on other sites

TGB1718

Link to comment

Share on other sites

tschak909

Link to comment

Share on other sites

dmsc

Link to comment

Share on other sites

tschak909

Link to comment

Share on other sites

+MrFish

Link to comment

Share on other sites

tschak909

Link to comment

Share on other sites

+MrFish

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members

Apps

My Activity Streams

More