There were a few made at various points but they were pretty unstable.
The DS actually has a display swap (or more accurately video engine output swap) command built into it
http://nocash.emubase.de/gbatek.htm#dspowermanagement
You then get to fiddle with bit 15. Some tried with with a simple cheat like 14000304 0000FFFF or 04000304 FFFFFFFF (it might have been 1 to begin with so you may have to change that to get a 0 in bit 15 instead)
However the better cheat would be something like reading the value and doing some boolean operation on the result to get the display swap bits to be the ones you want. However according to http://doc.kodewerx.org/hacking_nds.html the boolean operations are a hack and I am not sure what flash carts do what here.
Either way several people tried and I have not seen a properly successful version yet -- the screens will swap but it tends to come at a serious stability cost.
The DS actually has a display swap (or more accurately video engine output swap) command built into it
http://nocash.emubase.de/gbatek.htm#dspowermanagement
GBAtek DS power management section said:
You then get to fiddle with bit 15. Some tried with with a simple cheat like 14000304 0000FFFF or 04000304 FFFFFFFF (it might have been 1 to begin with so you may have to change that to get a 0 in bit 15 instead)
However the better cheat would be something like reading the value and doing some boolean operation on the result to get the display swap bits to be the ones you want. However according to http://doc.kodewerx.org/hacking_nds.html the boolean operations are a hack and I am not sure what flash carts do what here.
Either way several people tried and I have not seen a properly successful version yet -- the screens will swap but it tends to come at a serious stability cost.
It might be that the bit needs to be 0 instead, indeed given that it is engine a and engine a is what usually handles 3d that is likely the case though I still have to mention it is rarely a stable affair and getting it to be stable is likely to be no fun at all.
Try
14000304 00000FFF
It works in Desmume, though the touch screen might trouble things as the data you are supposed to be clicking on is not there but if you are good or you use buttons I guess it works well enough. Desmume is not real hardware though so anything could happen.
Try
14000304 00000FFF
It works in Desmume, though the touch screen might trouble things as the data you are supposed to be clicking on is not there but if you are good or you use buttons I guess it works well enough. Desmume is not real hardware though so anything could happen.
I assume you tried them one at a time -- together they would do odd things.
Several options at this point
1) The AR can not reach that memory section. This could be in general, could be because YSMenu's stuff is not so hot (by the way why YSMenu when Wood R4 exists?) or could be something else.
2) The section is being overwritten by something else and the cheat can not keep up. Seen it several times before.
3) The cheat is ineffective on real hardware for some reason other than 1) or in addition to it.
If you can then try applying the cheat with something like DSATM and also try it on Wood R4 unless you have a reason not to use it.
From here my next step would be to instead to apply it as an assembly hack (still possible in cheats mind you), however that is way more effort than I am inclined towards at this time of night. I would probably hook the game and write it rather than find what changed the POWCNT1 register though that is the second choice and probably the better one.
Several options at this point
1) The AR can not reach that memory section. This could be in general, could be because YSMenu's stuff is not so hot (by the way why YSMenu when Wood R4 exists?) or could be something else.
2) The section is being overwritten by something else and the cheat can not keep up. Seen it several times before.
3) The cheat is ineffective on real hardware for some reason other than 1) or in addition to it.
If you can then try applying the cheat with something like DSATM and also try it on Wood R4 unless you have a reason not to use it.
From here my next step would be to instead to apply it as an assembly hack (still possible in cheats mind you), however that is way more effort than I am inclined towards at this time of night. I would probably hook the game and write it rather than find what changed the POWCNT1 register though that is the second choice and probably the better one.
Err I can... it is just that it is not your basic hack (assembly is usually considered the last thing you learn in hacking and the hardest area depending upon what you are doing) so it could be quite a long response.
I realise now my offhand comment might have been read not how I intended it -- assembly is the more human readable translation of what ends up going through the processor, at this point you have to manage everything though as you are only making a tiny addition to the game or even change within it you do not have to do quite as much. However as the binary is loaded into memory and cheats can edit memory you can apply an assembly hack as cheats, the trick is getting to that point.
For learning assembly the docs from http://crackerscrap.com/index.php , http://www.coranac.com/tonc/text/asm.htm and a general guide to assembly/ROM hacking would be a start.
I realise now my offhand comment might have been read not how I intended it -- assembly is the more human readable translation of what ends up going through the processor, at this point you have to manage everything though as you are only making a tiny addition to the game or even change within it you do not have to do quite as much. However as the binary is loaded into memory and cheats can edit memory you can apply an assembly hack as cheats, the trick is getting to that point.
For learning assembly the docs from http://crackerscrap.com/index.php , http://www.coranac.com/tonc/text/asm.htm and a general guide to assembly/ROM hacking would be a start.
I'd love to be able to do this myself. But honestly, it's way out of my league.
I certainly wont be able to do this; and I don't see anyone else posting. So I guess that's it then.
Thanks anyway though.
I certainly wont be able to do this; and I don't see anyone else posting. So I guess that's it then.
Thanks anyway though.
After doing some research it appears that that code is bad because you are forcing all or the hardware on except the ARM9 that gets turned off! Also it might not work anyway because it is supposed to require halting the hardware briefly to change the settings.
It will require an asm hack code because the value in 0x4000304 needs to be ORed to 0x18000 and the ARDS lacks an OR code type. I will try to create one asap.
It will require an asm hack code because the value in 0x4000304 needs to be ORed to 0x18000 and the ARDS lacks an OR code type. I will try to create one asap.
Yeah such a code would be global, or at least as global as the injection method and dodging any game modifications to the areas in question (the number of games that would not work would likely small enough to consider making specific ones for them).
I was fiddling last night with the backlight codes to see if I could change something there but did not really take it anywhere.
"if not, could it be made? and if not (ha), why? i would expect the screen 'code' to be in the same place etc, i have no idea though... "
The screen position is located in a register (as in system register, not cpu register) which is what that code above I suggested attempts to fiddle with. In normal hardware though you kind of have to approach the situation properly it seems (emulators have no such issues for obvious reasons -- why emulate a restriction like that) and speak to it how you are supposed to (not sure of the full protocol, likely nothing too drastic though). http://nocash.emubase.de/gbatek.htm#dspowermanagement has more on that (though seemingly not the protocol).
To answer the other question that I can see being asked. You could turn this into a cheat (maybe even simple three to five line one) but that would quite possibly be unique to the game, you might be able to piggyback it off the likes of DSATM's injection though.
I was fiddling last night with the backlight codes to see if I could change something there but did not really take it anywhere.
"if not, could it be made? and if not (ha), why? i would expect the screen 'code' to be in the same place etc, i have no idea though... "
The screen position is located in a register (as in system register, not cpu register) which is what that code above I suggested attempts to fiddle with. In normal hardware though you kind of have to approach the situation properly it seems (emulators have no such issues for obvious reasons -- why emulate a restriction like that) and speak to it how you are supposed to (not sure of the full protocol, likely nothing too drastic though). http://nocash.emubase.de/gbatek.htm#dspowermanagement has more on that (though seemingly not the protocol).
To answer the other question that I can see being asked. You could turn this into a cheat (maybe even simple three to five line one) but that would quite possibly be unique to the game, you might be able to piggyback it off the likes of DSATM's injection though.
-
Xdqwerty
what are you looking at? -
Purple_Heart
-
@
Xdqwerty:
@Purple_Heart, i previously played it emulated, first the PS2 versión and then the Wii version
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
@Purple_Heart, then I will be actually older than him for a bit (ik thats not how ages work btw)
-
-
-
-
