At the moment it's not too easy since Mark has designed it out, for the most part. ie you're supposed to use the `preferred method` of doing it so that it is legal. On modern systems for example the os may not allow you access memory areas that you haven't pre-allocated and so on.
If you take a look at the Poke and Peek commands, you'll notice you can only poke and peek with a bank, and you have to specify the bank handle with every call.
However, you can work on addresses. For example, you can use VarPtr to get the address of a variable. You can then wrap that variable's memory space in a static bank (ie 4 bytes) and then you can Poke and Peek to the memory space of the variable.
You can also get the pointer to bank memory or the pointer to incbin'd file memory. But I am thinking that to modify the incbin file's memory you have to again wrap it in a static bank and access it via the bank with poke and peek.
The theory goes something like this - if you are behaving yourself and poking around in memory that you're meant to be able to access, you should be using the standard tools such as the static bank, poke, peek, etc. If you're not accessing memory that you own and have allocated properly, then why are you poking around in it?
I know it is useful, but alas BlitzMax more or less disallows you from doing it. This is Mark's effort to ensure that people adopt a certain programming practice, I guess, mostly for their own good.
You might want to look at using [0] on the end of a pointer, such as memaddress[0], because that then write to or reads from the content of the memory held at that pointer. You see, although we programmers interpret teh BlitzMax language in a certain way, if you think about it, there isn't much different between saying myarray[4] and myintpointer[4]. You can just strap on an index ie [0] and access the memory. Note however that if you use a byte pointer, it accesses individual bytes. Int pointers access groups of 4 bytes.
There's nothing to stop you modifying the pointer or using a different index such as memaddress[16]. You just need to get a pointer from somewhere. If the debugger complains that you're not allowed to do what you're doing, you could try compiling with debug off? So long as you know what you're up to.
For example to change the content of a function pointer I found you could convert the function pointer into a byte pointer, convert the byte pointer into an int pointer, and then use intpointer[0] to access the memory of that function pointer. This way you can directly read and write different values to the function pointer that wouldn't normally be allowed due to type restrictions. Usually you can't make a function pointer equate to anything other than another function pointer, so using this way (or with a static bank) you can access the memory of the function pointer and write to it directly.
I haven't really experimented all that much with putting [0] on the end of pointers, I guess you should be able to access any memory anywhere using that. It's kind of like the old assembler addressing mode called `indirect addressing`, where you get the content of the memory held at the address stored in a register (ie a variable points to the memory and then you read/write that memory).
And ... it should work on all OS's, but you may have problems with the o/s itself noticing that you're fumbling around in memory you don't `officially own` and might shut you out or think that your software is a crashed program running amuck. If you want to directly access memory you've allocated, you should be okay.
If you take a look at the Poke and Peek commands, you'll notice you can only poke and peek with a bank, and you have to specify the bank handle with every call.
However, you can work on addresses. For example, you can use VarPtr to get the address of a variable. You can then wrap that variable's memory space in a static bank (ie 4 bytes) and then you can Poke and Peek to the memory space of the variable.
You can also get the pointer to bank memory or the pointer to incbin'd file memory. But I am thinking that to modify the incbin file's memory you have to again wrap it in a static bank and access it via the bank with poke and peek.
The theory goes something like this - if you are behaving yourself and poking around in memory that you're meant to be able to access, you should be using the standard tools such as the static bank, poke, peek, etc. If you're not accessing memory that you own and have allocated properly, then why are you poking around in it?
I know it is useful, but alas BlitzMax more or less disallows you from doing it. This is Mark's effort to ensure that people adopt a certain programming practice, I guess, mostly for their own good.
You might want to look at using [0] on the end of a pointer, such as memaddress[0], because that then write to or reads from the content of the memory held at that pointer. You see, although we programmers interpret teh BlitzMax language in a certain way, if you think about it, there isn't much different between saying myarray[4] and myintpointer[4]. You can just strap on an index ie [0] and access the memory. Note however that if you use a byte pointer, it accesses individual bytes. Int pointers access groups of 4 bytes.
There's nothing to stop you modifying the pointer or using a different index such as memaddress[16]. You just need to get a pointer from somewhere. If the debugger complains that you're not allowed to do what you're doing, you could try compiling with debug off? So long as you know what you're up to.
For example to change the content of a function pointer I found you could convert the function pointer into a byte pointer, convert the byte pointer into an int pointer, and then use intpointer[0] to access the memory of that function pointer. This way you can directly read and write different values to the function pointer that wouldn't normally be allowed due to type restrictions. Usually you can't make a function pointer equate to anything other than another function pointer, so using this way (or with a static bank) you can access the memory of the function pointer and write to it directly.
I haven't really experimented all that much with putting [0] on the end of pointers, I guess you should be able to access any memory anywhere using that. It's kind of like the old assembler addressing mode called `indirect addressing`, where you get the content of the memory held at the address stored in a register (ie a variable points to the memory and then you read/write that memory).
And ... it should work on all OS's, but you may have problems with the o/s itself noticing that you're fumbling around in memory you don't `officially own` and might shut you out or think that your software is a crashed program running amuck. If you want to directly access memory you've allocated, you should be okay.