Post - Forum - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Forum Help

Post Your Message

Previous Messages

Posted By

Harry Potter
on 2024-02-20
19:42:49

Re: cc65/c16: problem w/ Cubbyhole technique

I believe I know what the bug in the 128k Plus4 version of AdvSkel65 is: I'm calling the verb functions the wrong way. I have the pointer to the function declared as:

void (* vfunc) (void);

and the code that reads the address and delegates the call as:


-------------------
#if defined __USEFARMEM__ && !defined __C128__
		vfunc=hidereadw((void*)&Verb[Vrb].vdo);
		(*vfunc) ();
#else
		(*Verb[Vrb].vdo) ();
#endif
-------------------

__USEFARMEM__ is declared on the compile command line, and hidereadw() reads the word at the given address in Hannes memory. When I add test code, the verb #, name and address are all correct, but, if I use verb other than the first in its database, I get either the wrong messages or a system crash. BTW, all the verb functions are declared as void vVerb (void);.

Posted By

Harry Potter
on 2024-02-20
19:05:14

Re: cc65/c16: problem w/ Cubbyhole technique

I found the error: the memory area "BASBUF" was overwriting two bytes needed by the kernal for display purposes. I shortened it and moved some stuff our of the memory area, and now the multi-part C16 version of AdvSkelVic65 works properly. However, when I tried to fix the 128k Plus4 version of AdvSkel65, I get a "Missing memory area assignment" from the linker. I need to figure out where the memory area is being used.

Posted By

Harry Potter
on 2024-02-20
08:08:11

cc65/c16: problem w/ Cubbyhole technique

Hi! I'm working on my AdvSkelVic65 and AdvSkel65 programs and am running into a problem: My emulator keeps crashing due to a JAM instruction being executed. The problem occurs in a location between $0200 and $02FF. I'm stuffing extra code there via my Cubbyhole optimization technique. I pasted the config file. Maybe a part of that area is being overwritten by the kernal?

---------------------------
SYMBOLS {
    __LOADADDR__:  type = import;
    __EXEHDR__:    type = import;
    __STACKSIZE__: type = weak, value = $0400; # 1k stack
#Size of used zeropage.  Change if necessary.
    __ZEROPAGESIZE__:type = weak, value = $0030;
}
MEMORY {
    ZP:       file = "", define = yes, start = $0002, size = $0030;
    #ZP2:      file = "stub5.prg",start=$0030, size = $0060;	# 96 bytes
    LOADADDR: file = %O,               start = $0FFF, size = $0002;
    HEADER:   file = %O,               start = $1001, size = $000C;
    MAIN:     file = %O,               start = $100D, size = $2FF3 - __STACKSIZE__;
    ZP2:      file = "stub4.prg",   start = __ZEROPAGESIZE__,
					size = $0090-__ZEROPAGESIZE__;
    BASBUF:   file = "stub1.prg",
			start = $01FE, size = $030E-$01FE;	#272 bytes
    TAPE:     file = "stub2.prg",
			start = $330, size = $0494-$0330;	#356 bytes
    BSTACK:   file = "stub3.prg",
			start = $065C, size = $07B2-$065C;	#342 bytes
}
SEGMENTS {
    ZEROPAGE: load = ZP,       type = zp;
    LOADADDR: load = LOADADDR, type = ro;
    EXEHDR:   load = HEADER,   type = ro;
    STARTUP:  load = MAIN,     type = ro;
    LOWCODE:  load = MAIN,     type = ro,  optional = yes;
    ONCE:     load = MAIN,     type = ro,  optional = yes;
    CODE:     load = MAIN,     type = ro;
    RODATA:   load = MAIN,     type = ro;
    DATA:     load = MAIN,     type = rw;
    INIT:     load = MAIN,     type = bss;
    BSS:      load = MAIN,     type = bss, define   = yes;
    INPUTH:   load = BASBUF,    type = ro;
    INPUTCO:  load = BASBUF,    type = ro,  optional = yes;
    INPUTRO:  load = BASBUF,    type = ro,  optional = yes;
    TAPEH:    load = TAPE,     type = ro;
    TAPECO:   load = TAPE,     type = ro,  optional = yes;
    TAPERO:   load = TAPE,     type = ro,  optional = yes;
    BSTKH:    load = BSTACK,   type = ro;
    BSTKCO:   load = BSTACK,   type = ro,  optional = yes;
    BSTKRO:   load = BSTACK,   type = ro,  optional = yes;
    ZP2H:     load = ZP2,      type = ro;
    ZP2CO:    load = ZP2,      type = ro,  optional = yes;
    ZP2RO:    load = ZP2,      type = ro,  optional = yes;
}
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__;
}