hal/video & pbkit video base address is hardcoded

[GXTX]

https://github.com/XboxDev/nxdk/blob/master/lib/hal/video.h#L12 https://github.com/XboxDev/nxdk/blob/master/lib/pbkit/outer.h#L6

pbkit is gross, but we use video.h alot so this should be updated.

fix

    HalReadWritePCISpace(1, 0, 0x10, &var, sizeof(ULONG), FALSE);

[JayFoxRox]

Why are you asking for this?

That's also where the kernel and other XBE expects it as far as I remember. There's hardly any good reason why it should be moved or why the code should probe for it.

For APIs like pbkit it might also become a performance issue if we have to do an indirect access instead of providing hardcoded addresses for very atomic standard operations (as you'd expect with the GPU).

There are very few components for which nxdk should allow MMIO relocation (in my opinion); primarily, MMIO relocation would make sense for the NIC, because there are very realistic use cases where you'd want to hook commercial games with a virtual NIC (emulating it is relatively easy) running on top of a real NIC.

For the other components I don't see many valid reasons, other than preparing some specific memory-layout, but at that point other parts of nxdk would also break along the way (even for a virtual NIC setup you'd probably need to leave much of nxdk behind / work-around issues with hooking games).

If really necessary, I guess an option could be some sort of hook system, where users could overwrite some config in a header / using the preprocessor. However, overall I'm skeptical if it's necessary to leave the original memory layout behind.

pbkit is gross, but we use video.h alot

I think pbkit is less problematic than much of video.h

pbkit is pretty ugly and does a lot of things poorly, but it's enough to bump the GPU into a working state (which is rather complicated). You can mostly use pbkit in tandem with other code. video.h on the other hand is mostly trivial stuff and very rigid.

[GXTX]

Base address can be changed in the xcodes, so we should not assume.

[JayFoxRox]

It's PCI and an insecure x86 system.. it can be changed wherever you want. Conceptually, however, x-codes are more or less the BIOS boostrapping phase of the Xbox; a much lower level than nxdk apps. If you modify the x-codes to relocate the MMIO regions, you'll almost certainly break the kernel and existing XBEs.

I feel like the kernel API and hardcoded memory layout are one of the core assumptions we should just accept, even if it can theoretically be modified. I'd feel differently if MS apps weren't hardcoded. But as far as I remember, they are (if they aren't, analyze how MS does it, so nxdk can emulate the behaviour for compatibility reasons).

nxdk aims to write Xbox applications that interface and co-exist with the existing Xbox OS (interfacing with the kernel and hardware, but also stick to many other conventions of XBEs). nxdk is not suitable for bare-metal apps like xbox-linux (where there are no assumptions as you are booting into a different OS).

You can still use nxdk for bare-metal apps but then you can't depend on many of the nxdk libs (which will have many assumptions about the environment). nxdk does not give you tools to relocate the MMIO regions either, and even if you did, you'd have to undo it.

As-is there are enough issues where nxdk breaks other XBEs such as #362. I believe that modifying other OS assumptions on purpose is opening a can of worms. We should aim to make nxdk stable with existing MS XBE assumptions / conventions first (assuming standard hardware / x-codes / kernel / ...).