Hi all, i'm trying to port one of my applications to the c64 using cc65. Problem is that it is pretty much code, so i need every byte i can find. Currently i have about 80% ported and got a "Memory area overflow in 'RAM', Segment 'BSS' (718 bytes)". What possibilities exist to handle that situation? I'd like to keep using a single PRG-File as long as possible... From the MAP-File: Segment list: ------------- Name Start End Size -------------------------------------------- ZEROPAGE 000002 00001B 00001A STARTUP 0007FF 000892 000094 INIT 000893 000928 000096 CODE 000929 009834 008F0C RODATA 009835 00A050 00081C DATA 00A051 00ADA3 000D53 BSS 00ADA4 00D2CD 00252A When reading the C64 memory map, we basically have: 0400 Screen memory 0800 basic A000 basic rom C000 upper RAM D000 char rom/vic/sid D800 color RAM DC00 CIA DE00 I/O-Area E000 Kernal ROM The prg currently has a filesize 38.652 bytes. I've seen working PRGs with up to 59kB so it should be possible... My app configures the VIC area so it has its screen at 0xE400, colors at 0xD800, using its own charset at 0xE800, and three sprites at 0xCF00 (which should conflict with code..mhhh). So, could i: 1) load the app to 0400 instead of 0800 and still start it normally? 2) could i switch i/o-area and/or Kernal to RAM and use these areas for code? (how much of the kernal is needed - i need to use file-i/o?) 3) is it possible to split code into non-continous memory regions (without doing it "by hand" in assembly) 4) i have a 2k const array for the charset - what is the best method for not wasting that memory, after the charset has been copied to its final destination. Can i locate one of my global arrays of structs at the same location? 5) can i place the arrays with sprite data at a 64 byte boundary so they can be used directly without relocating? 6) Other suggestions? thanks, Andreas ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sat Nov 17 21:21:05 2007
This archive was generated by hypermail 2.1.8 : 2007-11-17 21:21:08 CET