pbkit is not 128MB aware

[GXTX]

Because of this, it will only allocate memory in the lower 64MB portion.

#define MAXRAM 0x03FFAFFF

Is used in many places.

HalReadWritePCISpace(0, 0, 0x84, &var, sizeof(uint32_t), FALSE);

Will give you RAM size, however some scene kernels do not set this properly even if you have 128MB, so you could also read NV_PFB_CFG1.

pb_OldVideoStart=((DWORD)XVideoGetFB())&0x03FFFFFF;
Is also probably problematic.

[JayFoxRox]

HalReadWritePCISpace(0, 0, 0x84, &var, sizeof(uint32_t), FALSE);

Will give you RAM size, however some scene kernels do not set this properly even if you have 128MB, so you could also read NV_PFB_CFG1.

I don't think any of this is a valid option.
Also some kernels will move other resources inbetween the 64MiB banks, so I'm not sure if the MAXRAM is that bad after all.

128MiB patches on Xbox are a huge mess, but it's not the fault of nxdk.
128MiB by MS was intended as 64MiB retail use + 64MiB debug use. The scene took this and marketed it as 128MiB retail.
For Chihiro it was different, and the memory layout is more suitable for 128MiB.

If your app wants to be 128MiB compatible, I suggest to probe for 128MiB yourself, and potentially bring your own drivers and kernel patches?
pbkit should probably allow some sort of config hook, but I don't think we should make it more fragile than it already is, for a niche use-case.

[GXTX]

video.c already has patches to support 128MB, pbkit should too.

[GXTX]

Played around with this on my fork and it's came up with a non-functioning solution. master...GXTX:feat/pb_kit_128_aware

Seems there's more going on.

[Ryzee119]

The following call may be a better way of determining available RAM?

MemoryStatistics.Length = sizeof(MM_STATISTICS);
MmQueryStatistics(&MemoryStatistics);
ULONG mem_size = MemoryStatistics.TotalPhysicalPages * PAGE_SIZE;

pb_OldVideoStart=((DWORD)XVideoGetFB())&0x03FFFFFF;
Is also probably problematic.

Yea this should probably use the MmGetPhysicalAddress function