Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: "Wayne K. Werner" Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: pixels Date: 21 Jul 1997 02:17:08 GMT Organization: SCEA Net Yaroze News Lines: 67 Message-ID: <01bc957c$2b7fa440$9fbf43ce@wkwerner> References: <33c122d9.168381829@news.scea.sony.com> <33c14f5a.23551302@205.149.189.29> <33c29ffb.95879061@news.scea.sony.com> NNTP-Posting-Host: port59.con2.com X-Newsreader: Microsoft Internet News 4.70.1155 Jamin Frederick wrote > Speaking of memory, I've been sticking all my stuff at > 0x80090000. This is the bottom of what we get to use. This grows > upward with picture and sound data and stuff until it hits > something...but what's up there, the program stack? I don't know > what's going on up there towards the top of the mapped main > memory...the top of main memory, according to the manual, is > 0x801fff00. You can tell your compiler to put the program at, say, > 0x801e3000. But this gets loaded upwards, starting at 0x801e3000, up > to the top 0x801fff00 (adjust this according to your executable size). > So your program stack grows downwards from 0x801e3000, until it hits > data? > What about the resident "bricks" loader program...where's that stored? > Hey, Jamin. Thanks for the one sprite program. I've been fiddling with it, and it has been very helpful. In porting your demo over to CW, I ran into some problems that got me looking into the above memory issues. CW, by default sets the program start address at 80090000. I see that you were loading the tim data there. I guess that you have been setting the load address of your program to a value above all of your needed data. Perhaps you would be better served by placing the program at the default 80090000 and find the end of the program (generate the map when linking and look at the value of the linker defined variable _end). It seems that between 80090000 and _end is contained all of the code and data of all types, including the heap. There is a linker variable called _heap_size with a value of 0x400. A paltry amount for the heap! I have yet to find a linker flag to change this value. (Any MW people lurking?) However, the point is that _end points to the beginning of all *unused* space after your program. You can load tims, or anything else for that matter, into this space to your hearts delight! BTW all of the linker supplied variables are accessable in your programs by including __rts_info_t__.h, which is used by _psstart.c. Imagine the possibilities of a program determining its end and slicing up the memory any way it wishes. Maybe the small heap is a blessing instead! You can even use this area as a buffer for loading anything from new data to levels to overlays, etc. And yet, the stack looms over your head like the Sword of Damacles. The documentation says that the system stack occupies the last 1/4 kbyte of main mem. (801FFF00 to 801FFFFF) so the program stack should start at 801FFF00. CW appears to default to 801FFFFF. Well without getting into the pre-decrement post-increment nature of stacks, this number is BAD! First of all, to set the stack to the top of memory, 80200000 would be the correct number. But this is where the system stack is supposed to be! The stack for your project should start at 801FFF00 (change this in your targets linker options.) I haven't checked, but this is probably the reason that the CW compile of one sprite doesn't come back after exiting... the system stack has been trashed! I will make this fix and see what happens. As far as I can tell, there is no stack checking. Yup, get too recursive, or load too much data into that *unused* space, and you will be colliding with your stack. A painful thing indeed! When debugging a program, you might want to occassionally look at the stack pointer to see if you are playing on the edge or not. I will post this as a new post in the CW news section also. God, I love a good geeky dialog on system memory layout! -- Wayne K. Werner wkwerner@con2.com