On 11/11/2010 12:54 AM, Christian Grössler wrote: > > One idea was to have a "check load address" segment, which verifies that > the selected load address of the exe isn't too low and will overwrite parts > of DOS. Since I haven't found a way to abort the loading of the next memory > segment(s), all it could do is issue a warning, that the program overwrote > parts of DOS and the machine will later probably crash. At least better > than a crash without anything indicating the reason of the crash, IMO. IMHO its enuff to ive the warning. There are cases when you do not need a DOS and want to use all memory from $600 upwards. Maybe we can copy $700-$26ff to $e000-$ffff so teh program can exit cleanly. When you use the DOS memeory for dynamic data (aka after the C prgram has loaded) it would even be loadable from DOS ;) > > Another idea was to create a new "atarixl" configuration (similar to apple2 > and apple2enh), which copies the ROM into it's underlying RAM and adds > some usable space there to the heap. Code for this was posted by Fatih > Aygün > some time ago. The first exe load segment could do this and then be > overwritten > by the later load segments of the program, therefore not using up memory > at runtime. > In this "atarixl" configuration, since we can expect a machine with 64k > of memory, the INIT segment could also be loaded after the BSS and not > consume runtime memory since it's residing on the stack area. Ermmm... maybe your explaination is wrong worded, but when we copy the ROM ($c000-$cfff and $e000-$ffff) into teh underlaying ROM (same memroy regions) how do we gain more memory for the C program? We wouldl get more RAM when we copy C functions under the ROM and have a possibility to call them in a special way (switching off OS/IRQs, calling, switching on OS/IRQs after return). ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Thu Nov 11 06:55:57 2010
This archive was generated by hypermail 2.1.8 : 2010-11-11 06:56:00 CET