WiiVC Memory Setup

NOTE:
MEM1 has to be lower on NTSC because of CIC chip emulation occuring only in the Fishing Pond which allocates extra RAM (83936 bytes)!

Strategy:
-Game code ends at 0x8025F0B8
r13 = 0x802647C0
r2 (rtoc) = 0x80265E40
r1 (SP) = 0x8026F0B8

MEM1:
-Move MEM1 ArenaLo from 0x802710C0 to 0x802E10C0 (+0x70000)
-Keep ArenaHi as is (0x81800000)
-App entry point should be: 0x80272000 (securely past game code, small mem regions and the main thread stack)
-MEM1 Heap Size: 0xD000
-MEM1 Heap should use OSGetMEM1ArenaLo() - HEAP_SIZE to find the start point for the heap dynamically (ensure it ends before ArenaLo starts)
-This gives us 401.6 KB of workable space for code and data in MEM1

NTSC: 8008a080
; lis r3, 0x802e Use 802e10c0 as MEM1 ArenaLo instead of 802710c0
u32 0x3c60802e

JP:


MEM2:
-Move MEM2 ArenaLo from 0x90000800 to 0x90400800 (+0x400000)
-Keep ArenaHi as is (0x935E0000)
-MEM2 Heap Size: 0x400000
-MEM2 Heap should use OSGetMEM2ArenaLo() - HEAP_SIZE to find the start point for the heap dynamically (ensure it ends before ArenaLo starts)
-This gives us 4194.30 KB of workable space for data in MEM2

NTSC: 8008a118
; lis r3, 0x9040 Use 90400000 as MEM2 ArenaLo instead of 90000800
u32 0x3c609040

; ori r3, r3, 0x800 Use 90400800 as MEM2 ArenaLo instead of 90000800
u32 0x60630800

JP:


For dynamic memory:
-MEMInitAllocatorForFrmHeap has less overhead and fragmentation risk. Could use one set of news for temp list, delete entire space again after init. Then allocate from the bottom for the permanent watch list and change new to only allocate from the top after that. Each processingThread loop then allocates everything from the top and uses MEMFreeToFrmHeap with mode 1 (MEM_FRMHEAP_FREE_HEAD) once at the end of each cycle to clear the entire space for the next cycle without touching the permanent watch list (also skips a bunch of deletes). On reset can clear everything with mode 3
-Values (valuePtrs) when reading or task creation happens should be allocated from MEM2 and properly freed (so the host can read the 32 KB SRAM for example)
-When managing heaps, avoid the MEM_HEAP_OPT_THREAD_SAFE flag as we only have a single point of access (not shared between threads)

Safe for frame heap:
MemoryAccessor
WriteCondition
QueueTaskGeneric (need to watch for queueTaskPtr if QueueTaskWrite)
TaskEntry

Unsafe for frame heap:
QueueTaskWrite (vector)
WatchEntry (vector)
WatchEntryUpdate (can be cached ; includes all children)
CallbackValueWatchEntry (can be cached ; includes all children)
TaskResult socket (can be cached ; includes all children)
TaskResult watcher (can be cached ; includes all children)
TaskResultRead (can be cached ; includes all children)




App Flow:
-OSInit creates the default arenas. 0x802710C0 - 0x81800000 (MEM1) and 0x90000800 - 0x935E0000 (MEM2)
-setupMainAppHeap moves both ArenaLo to the end (blocking the entire space)
-A custom allocator and free function manages both spaces as a giant unified heap:

bool customMalloc(int *outPtr, u32 size);
void customFree(int *ptr);
(code see: https://github.com/zeldaret/oot-vc/blob/master/src/virtual_console/xlHeap.c)

customMalloc decides whether MEM1 or MEM2 is used depending on if the size is >= 40000000 ((size >> 30) & 1). True is MEM2, otherwise MEM1 is used. Max size is 16.7 MB (0x1000000) and the function automatically aligns the size to blocks of 32

-The system default heap plays no role
-OSAllocFromHeap is rigged to use customMalloc instead. The size is automatically added to 0x70000000 to force MEM2 usage
-OSFreeToHeap is rigged to use customFree instead

-Sub heaps can be created and managed by allocating space from customMalloc and then letting the extended Memory lib handle it (MEMCreateExpHeapEx, MEMInitAllocatorForExpHeap, MEMAllocFromAllocator, MEMFreeToAllocator)
-Sub heaps are especially good practice from threads and used there so the main heap manager doesn't have to constantly lock/unlock a mutex and force other systems to wait


Memory Details:

MEM1: (Original NTSC)
Normal: 0x80000000 - 0x817FFFFF (game code ends at 0x8025F0B8)
Lo: 0x802710C0 (later moved to 0x81800000 by setupMainAppHeap)
Hi: 0x81800000
createAppHeap is called with: 0x817FFFFC, 0x00553A2A, 0x0011EBB1

With 4 MB N64 RAM:
manageHeap function is called with:
802710C0 (ArenaLo)
802710d8
802b10f8
809b31d4
80af9034
80df9054
80efd074
80f43594
81364138
8137646c
813805ac
81386c74

Allocated after boot:
81386cdc (loading a file)
81386d20 (home menu)
81387d40 (home menu)

Game only allocates up to 0x81388000 at most (18 MB). 0x81388000 - 0x81800000 should be free. 0x478000 (4685824) = 4.68 MB


With 8 MB N64 RAM:
manageHeap function is called with:
802710C0 (ArenaLo)
802710d8
802b10f8
809f2458
80efd074
80f43654
80f66138
81764138
81786a08
81786c74

Allocated after boot:
81786cdc (loading a file)
81786d20 (home menu)
81787d40 (home menu)

Game only allocates up to 0x81788000 at most. 0x81788000 - 0x81800000 should be free. 0x78000 (491520) = 491 KB = 491 KB space total (use 20 KB of that for an Exp heap for new/malloc allocations)

Allocator test: Max safe allocation is 0x79300 (0x79400 fails) (496 KB)


MEM2: (Original NTSC)
Normal: 0x90000000 - 0x93FFFFFF (upper 12-16MB used by system, game leaves 10.6 MB free)
Lo: 0x90000800 (after boot: 0x933E0000, set by setupMainAppHeap)
Hi: 0x935E0000

createAppHeap is called with: 0x933DFFFC, 0x250D7E
manageHeap function is called with:
0x90000800 (ArenaLo)
90096820
9012c840
9014c860
9016c9a0
92a9ca00

Allocator test: Max safe allocation is 0x8F0000 (0x708F0000) (0x900000 (0x70900000) fails) (9371648 bytes = 9.37 MB)


MEM2: (With 32 MB ROM patch instead of 43 MB)
manageHeap function is called with:
0x90000800 (ArenaLo)
90096820
9012c840
9014c860
9016c9a0
92a9ca00

Allocator test: Max safe allocation is 0x1440000 (0x71440000) (0x1450000 (0x71450000) fails) (21233664 bytes = 21.23 MB)