Lockup with Basic ROM active

[danwinslow]

I've noticed that after a certain size, my CC65 compiled programs seem to lock up when they load...if Basic is enabled. If I boot with Basic disabled, they run fine. So, obviously I am running into some part of the memory that the Basic ROM uses...but what is it, I wonder. Is it the parm stack ( at high end of memory ), or program code getting loaded into the ROM space, or me trashing something like the FP routines. Anyone have any suggestions about how to investigate this? I am using the standard CC65 linker config on a 130xe and Sparta.

[Rybags]

Upload a short example of an executable so we can have a look.

[cas]

I've noticed that after a certain size, my CC65 compiled programs seem to lock up when they load...if Basic is enabled. If I boot with Basic disabled, they run fine. So, obviously I am running into some part of the memory that the Basic ROM uses...but what is it, I wonder. Is it the parm stack ( at high end of memory ), or program code getting loaded into the ROM space, or me trashing something like the FP routines. Anyone have any suggestions about how to investigate this? I am using the standard CC65 linker config on a 130xe and Sparta.

1021319[/snapback]

 

Hi,

 

most probably your CC65 code is getting large and is overwriting the Screen memory during load. Can you please run a tool that is printing out the COM-File header (for example HEA in Turbo-DOS).

 

Important here is the OS Pointer MEMTOP ($2E5, $2E6), pointing to the top memory usabe for application programs. Above this memory location, there is the Displaylist and the Screen memory. If basic is disabled, MEMTOP is pointing at $BC1F. This is the maximum address your program can use. If BASIC is enabled, MEMTOP is pointing to $9C1F. $2000 bytes above the Screen Memory and Display List are now used for the BASIC ROM, using 8KB (=$2000 Bytes).

 

Best regards

 

Carsten Strotmann

[danwinslow]

Well, here's what dis6502 has to say :

 

segments for AEFTP.COM

$2E00-$839F:21920 ($55A0)

$02E0-02E1:2 ($0002)

 

 

This is on a stock 130xe with disk spartados.

[cas]

Well, here's what dis6502 has to say :

 

segments for AEFTP.COM

$2E00-$839F:21920 ($55A0)

$02E0-02E1:2 ($0002)

 

 

This is on a stock 130xe with disk spartados.

1021470[/snapback]

 

Does your program use Graphics 0 (Text) Mode, or any Graphics Mode like Graphics 8? A Graphics mode will push MEMTOP down, so it might be that you already crossing the MEMTOP boundary overwriting the Displaylist and Screen Memory. If you have a kind of Monitor-Enabled ROM (or use the Atari800 Emulator build-in Monitor) to stop the computer after the crash and excamine MEMTOP ($2E5, $2E6). If it is lower than $839F, you need to strip down your program, either by

 

a) trying to write denser code

b) putting data or code in the extended 130 XE Memory

c) load overlay code or data from Disk

d) recoding in FORTH might help

 

Best regards

 

Carsten

[danwinslow]

hehe. Thanks Carsten

 

No, no graphics calls at all.

 

a) I am fairly dense already.

b) I have this planned, but this is a code issue I believe rather than data.

c) maybe..need to learn more first.

d) CC65 is heavier than FORTH, thats true. But I can cut a lot out of it by replacing the printf() family with conio and going back and doing some smarter coding.

 

I'll post the source if I need to but its pretty lengthy.

[cas]

d) CC65 is heavier than FORTH, thats true.

1021505[/snapback]

Well, it's not always true. You can write as dense as Forth in C, by using Forth like coding style. But I know that is often not an option, so this was not meant seriosly.

 

 

When does the lockup occur? Direct while loading, or when starting, or after some time? You might want to add manual "debug-points" in you program, print the content of MEMTOP and see if your programm is crossing this. It might also that the CC65 heap is crossing the border, writing past the MEMTOP value.

 

Carsten