Uz, Oliver, Thanks for the help! > The code above copies up to 255 bytes. Maybe you want to check your > map file if the DATA segment is already larger than 255 bytes... The size of my DATA segment is $8F. I know my copy code will only copy up to 256 bytes, but I didn't worry about that yet as I'm still under that limit. Here is the finalized segment values: Name Start End Size Align ---------------------------------------------------- ZEROPAGE 000055 00006E 00001A 00001 DATA 00040D 00049B 00008F 00001 ZPSAVE 00049C 0004B5 00001A 00001 BSS 0004B6 0004E4 00002F 00001 INIT 00B000 00B02E 00002F 00001 CODE 00B02F 00B821 0007F3 00001 RODATA 00B822 00C020 0007FF 00001 STARTUP 00D3B6 00D432 00007D 00001 > * The startup module contains code to chain the kernal IRQ handler. Are you > sure this works with your setup? It might be better to remove that code > until you need it. I have yet to implement any IRQ handling and I have stepped through the startup segment to verify that the NoIRQ label is hit, which calls initlib. Maybe I will remove all of IRQ chaining stuff just to be sure. > * How about the zero page? You just define it as starting from $00. Are you > sure, that the first 26 bytes can be used by the runtime? This was my ignorance of the architecture I suppose. I read about zeropage a bit and as the name implies, discovered it should be the first page. This is why I have chosen $00. Since my last email, I have editing my LD configuration, restoring the default addresses for ZP and RAM from pet.cfg. My memory map now looks like this: MEMORY { ZP: file = "", start = $0055, size = $001A, define = yes; RAM: file = "", start = $040D, size = $8000 - __STACKSIZE__ - 100; ROM: file = %O, start = $B000, size = $23B6, fill = yes; STARTUP: file = %O, start = $D3B6, size = $0C4A, fill = yes; } Unfortunately, this made no difference. > The zero page locations used > by the runtime should be choosen so that they don't interfere with other > code that might be running (the kernal for example). I'm not sure how to do that. Should using $1A as above leave enough space for the kernal and it's IRQ handlers? Is there a method I can follow to determine what that value should be? I have indeed checked the address of cprintf (I'm using labels generated via -Ln) and through the monitor, I can follow the execution path from my code all the way through: cprintf -> _vcprintf -> __printf From there, the routine eventually call .CallOutFunc, which makes another jump, but this time in to uninitialized space: .C:0491 .CallOutFunc: .C:0491 4C 78 9A JMP $9A78 (C:$04bb) d $9A78 .C:9a78 9A TXS It's like the stack is corrupt, or some internal library state is has gone awry... I'll keep at it. Please share any opinions or ideas, things I should be checking. I appreciate any and all feedback! Cheers, Darryl ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri, 18 Jan 2013 16:39:06 -0500
This archive was generated by hypermail 2.1.8 : 2013-01-18 22:39:28 CET