Login
Back to forumReply to this topicGo to last reply

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__;
}


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
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);.



Back to topReply to this topic


Copyright © Plus/4 World Team, 2001-2024