ISO Loader 0.6.x Beta

[SWAT]

(25.11.2020 12:48)sundance2 писал(а):  

(25.11.2020 07:18)SWAT писал(а):  But note that full loaders (sd_cso.bin and sd_cso_alt.bin) are already using too much memory to be placed in the default address (0x8c004000). Only sd_cso_se.bin can be placed there.
For full loaders with cso you should use 0x8c000100 or high memory.

Is there a place where the reasoning behind memory address selection is explained ?
For example, is it generally better for the loader to start at a lower address, while it's generally better for the software being run that the loader be placed at a rather higher address ?

This part is nebulous to me, the ISO loader proposes a lot of addresses, but without explanation, I tend to blindly follows config lists like the dragoncity one,
yet I see other people/video suggesting different address, and after testing, many of them work, so it's really not satisfying to understand why select one rather than the other.

@swat post states that one parameter for this choice is the binary size of the loader, suggesting that the "right" address depends on the loader and its version. Maybe on other parameters? or even the image being loaded too.

As a data point, `sd_cso.bin` is 30.5 KB,
compared to previous betas of `sd.bin` :
v0.6.11 => 28.6 KB
v0.6.10 => 27.6 KB
v0.6.9 => 27.3 KB
v0.6.8 => 26.9 KB
So it seems to be slowly growing overtime (even without cso support).
And presumably, it could have an impact on address selection.

Loader memory usage:
params (1KB) + loader code (nKB) + buffer (32KB - params - loader). Max 32KB.

In best case, for buffer need 2KB (one sector). This buffer uses only for non-optimized images and little for CDDA (track name). So the loader should be less than 29KB.
In future this buffer I will made as *dynamic* too, but it's working not in all games yet.

Also loader uses additional memory (up to 32KB) for CDDA and/or CISO buffers.
For CDDA now supported dynamic, for CISO still not, it uses only hardcoded addresses.
And CDDA can use hardcoded addresses if dynamic disabled (not supported).
You can see here:
https://github.com/DC-SWAT/DreamShell/bl...?ts=4#L220

Application (KATANA game) memory usage:
Params: 0x8c000000 - 0x8c000100 (also here vectors for syscalls)
Syscalls: 0x8c000100 - 0x8c004000
Stack: 0x8c004000 - 0x8c00f400 (in some cases at 0x8d000000)
VBR: 0x8c00f400 - 0x8c010000 (in some cases in heap)
App binary: 0x8c010000 - ???
Heap: ??? - 0x8d000000

So we can place loader (and buffers) in the heap (carefully with stack if it's at the end) or at 0x8c000100 - 0x8c004000 because loader can emulate all syscalls.
Best choice it's a 0x8c004000, we don't touch original syscalls (just change some vectors) and don't conflict with game, because stack here is usually does not grow much and VBR code block is 3KB, so we should have ~ 32KB for free.
But some games can write in this memory area some "loaders" or stack grow so much and do damage loader code. So we should move loader at high memory (heap) and hopes we are lucky