+SpiceWare Posted July 1, 2021 Share Posted July 1, 2021 By default the the ARM's 8K of RAM is configured as: 2K CDFJ Driver (or 3K DPC+ driver) 4K Display Data 2K C Usage for Variables, RAM Functions, and Stack (or 1K if using DPC+) 2K of space for C usage can be used up quickly if you're keeping track of a lot of objects, such the positions of 159 sprites that are in Draconian, or if you're putting functions in RAM for a performance boost. If you're not using the full 4K of Display Data you can reallocate part of it for C Usage. The division between Display Data and C Usage is controlled by the ram entry in the MEMORY section of the custom.boot.lds file, located in the custom directory: MEMORY { boot (RX) : ORIGIN = 0x800 , LENGTH = 0x80 /* C-runtime booter */ C_code (RX) : ORIGIN = 0x880 , LENGTH = 0x6780 /* C code (26K) */ ram : ORIGIN = 0x40001800, LENGTH = 0x800 /* 2K free RAM */ } If you're going to change it the best practice is to: duplicate the ram entry comment out one of them by putting /* before ram and */ after 0x800 edit the duplicate entry As an example we will reallocate 1K of Display Data to C Usage. Both ORIGIN and LENGTH need to be adjusted by the amount - subtract from ORIGIN, add to LENGTH. (1K = 0x400). MEMORY { boot (RX) : ORIGIN = 0x800 , LENGTH = 0x80 /* C-runtime booter */ C_code (RX) : ORIGIN = 0x880 , LENGTH = 0x6780 /* C code (26K) */ /* ram : ORIGIN = 0x40001800, LENGTH = 0x800 */ /* 2K free RAM */ ram : ORIGIN = 0x40001400, LENGTH = 0xC00 /* 3K free RAM, took 1K from Display Data */ } Warning: do not forget to update your Initialize routine so it does not override the RAM that has been reallocated for C Usage. This is especially critical if you have put functions into RAM for a performance boost. void Initialize() { ... // 1K of Display Data RAM was given to C Variables and Stack. // this is done in custom.boot.lds myMemsetInt(RAM_INT, 0, 3072/4); // When the Harmon/y Melody is powered up the 4K of Display Data RAM will // contain random values, so we should zero it out to have a known starting // point. Using myMemsetInt is faster than using myMemset, but requires // dividing the number of bytes by 4 because an integer is stored in 4 bytes. // myMemsetInt(RAM_INT, 0, 4096/4); ... } In Speed boost - run code in RAM the location of the functions that ended up in RAM can be seen in armcode.map: 0x0000000040001800 RAM_BitReversal 0x0000000040001828 RAM_ColorConvert 0x000000004000185c RAM_PrepArenaBuffers After changing custom.boot.lds the RAM functions now start at 0x40001400 instead of 0x40001800: 0x0000000040001400 RAM_PrepArenaBuffers 0x0000000040001570 RAM_BitReversal 0x0000000040001598 RAM_ColorConvert Source Collect3RAMallocation.zip 2 Link to comment Share on other sites More sharing options...
Recommended Posts