Reallocate ARM RAM

[+SpiceWare]

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:

1. duplicate the ram entry
2. comment out one of them by putting /* before ram and */ after 0x800
3. 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