Current code (eb69c7fba9cdd1bb1e81eec60f4fed4394a42c67):
def xbdm_hack(address, operation, data=0):
SetMem(hack_bank, struct.pack("<III", address, operation, data))
xbdm_command("resume thread=0x" + format(hack_bank, 'X'))
return GetMem(hack_bank + 8, 4)
(Also see xbdm-hack.md for more information)
Here is what the hack does for reads and writes:
Reads
def xbdm_read_8(address):
return xbdm_hack(address, 1)
xbdm_hack will call SetMem, which is the first communication with Xbox, to setup the next step
xbdm_hack will call xbdm_command which is another communiation with Xbox
xbdm_hack will readback the result which is another communication with Xbox
That is 3 back-and-forth transfers for a single read.
Writes
def xbdm_write_8(address, data):
xbdm_hack(address, 4, int.from_bytes(data, byteorder='little', signed=False))
xbdm_hack will call SetMem, which is the first communication with Xbox, to setup the next step
xbdm_hack will call xbdm_command which is another communiation with Xbox
xbdm_hack will readback the result which is another communication with Xbox, even if it isn't returned from xbdm_write.
That is 3 back-and-forth transfers for a single read, with one of them being completly useless.
There's various ways to optimize it.
Calls
def xbdm_call(address, stack):
assert(len(stack) < 64)
SetMem(hack_bank + 12, stack)
return xbdm_hack(address, 7, len(stack))
xbdm_call will call SetMem, which is the first communication with Xbox
xbdm_hack will call SetMem, which is the more communication with Xbox, to setup the next step
xbdm_hack will call xbdm_command which is another communiation with Xbox
xbdm_hack will readback the result which is another communication with Xbox
Ideally we'd pass all optional input data in the xbdm_hack request, and return all optional output data in the response.
Maybe we should also allow packing of commands, simply to avoid XBDM command processing overhead.
Current code (eb69c7fba9cdd1bb1e81eec60f4fed4394a42c67):
(Also see xbdm-hack.md for more information)
Here is what the hack does for reads and writes:
Reads
xbdm_hackwill callSetMem, which is the first communication with Xbox, to setup the next stepxbdm_hackwill callxbdm_commandwhich is another communiation with Xboxxbdm_hackwill readback the result which is another communication with XboxThat is 3 back-and-forth transfers for a single read.
Writes
xbdm_hackwill callSetMem, which is the first communication with Xbox, to setup the next stepxbdm_hackwill callxbdm_commandwhich is another communiation with Xboxxbdm_hackwill readback the result which is another communication with Xbox, even if it isn't returned from xbdm_write.That is 3 back-and-forth transfers for a single read, with one of them being completly useless.
There's various ways to optimize it.
Calls
xbdm_callwill callSetMem, which is the first communication with Xboxxbdm_hackwill callSetMem, which is the more communication with Xbox, to setup the next stepxbdm_hackwill callxbdm_commandwhich is another communiation with Xboxxbdm_hackwill readback the result which is another communication with XboxIdeally we'd pass all optional input data in the
xbdm_hackrequest, and return all optional output data in the response.Maybe we should also allow packing of commands, simply to avoid XBDM command processing overhead.