From: Christian Groessler (chris_at_groessler.org)
Date: 2003-09-18 00:56:55
On Wed, 17 Sep 2003, Shawn Jefferson wrote: > On Wed, 17 Sep 2003 23:41:56 +0200 (CEST), Christian wrote: > > >Hmm, I don't think that the stack resides inside your assigned memory > >areas. > >By default, the runtime assumes the largest possible memory use for > >graphics (graphics 9) and adjusts the stack pointer accordingly. So the > >stack pointer would initially be around 8k below MEMTOP. > > Well, when I run my program without _graphmode_used = 0, I get MEMTOP > as BC1F and the sp (at $0082 right?) is a couple of bytes below BC1F > and as my program runs it gets a few more bytes below that... I looked again, and, yes, the graphics memory reservation is only done if you use the graphics() function in your program. It seems that documentation is really needed, as I myself forget what I've programmed ... :-/ > What I did was to calculate my pointers from MEMTOP. My grid bitmap > is now calculated as MEMTOP - 255 - 2560 (64 lines of mode D) and my > P/M area is grid_bmp.dat - 2048 & ~2047. This sort of gets around the > problem of the stack in upper memory, but my other memory areas are > hard-coded still. > > I guess I should calculate them as well, by the address of the screen > ram. Then my program will be able to run on different setups where > MEMTOP and screen ram is set differently. But they are still indirect pointers. What about using low memory (upping the load address) and using them hardcoded again? Could give a small speed advantage. regards, chris ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-09-18 00:58:39 CEST