found another bug with the 8 bit load and stored instructions on the latest build.
using this code (junk code made for debugging)
its effecting the byte next to it and zeros it out.
so for example in mkds
b6 30 in the arm7 memory viewer is what its should be but its
b6 00 instead. the byte next to b6 shouldn't be effected. so i guess it writing in 16 bit instead of 8 bit?
i actually wasn't planning to do a bug report i just happen to find that when i used.
Remember when i said ar codes should still have the option to run on the arm9 and arm7 cpus via optional tic box i have a friend that makes codes for games and he said he can get ar codes to work in higher adress regions i told him its cause ar codes arnt running on arm9 anymore. so i had to give him an old version that still ran on the old code with all the bugs so he could make some camera control codes for zelda and animal crossing.
i still think ar codes should have the option to run on the full range of ram cause sometimes ar codes are needed since internal codes dont have code type instructions like ar code. So can it be implemented to have an optional tic box to access arm9 and arm7 cpus with ar codes? plus from a few years ago a lot has changed in desmume for bugs and features.
Last edited by fintogive (2017-04-06 04:54:49)
yep, D8 was bugged in the exact way you perceived. I just fixed it.
IMO you guys should invest resources in making lua scripts if you are going to be making cheat codes that can ONLY WORK ON DESMUME due to it's support of a mythical arm9 AR code.
But if you want to run AR codes on ARM9, then here's how you should do it. Carefully analyze the available AR codes and choose a new unused one which sets the code to run on the ARM9 instead. You will use that code at the beginning of the code list to specify an ARM9 code. That way nobody will get them confused with ARM7 AR codes. Like, I haven't thought about it much, but how about 0xDFFFFFFF 99999999 (first part chosen to be least likely to be used by any future cheat device, and also look fishy, 99999999 chosen for obvious reasons). Make a formal proposition and I'll consider it.
Perhaps we can 77777777 can be used to change back to arm7, and we can define the code to take effect at the instant when it is run.
We could have DFFFFFFF XXXXXXX9 set other options (to be determined) as well as set to arm9, but I can't think of any other options, and I think it's valuable to blast a screen full of 99999999 at the user so he has no excuse for not knowing it's an ARM9 code that won't work on real hardware. But maybe you and your cheating pals have other things on your wishlist, if we're inventing a mythical standard here.
So if i understand this correctly make a special code type instruction unique to desmume to allow it to run for example, in the 0x01000000 address region?
as for lua scripts we are ar code experts but dont know anything about making lua scripts. i know strange isnt it. so do you need my friends ar code?
i don't need his AR code. I fixed the code.
Yes, you understand correctly. We could allow it to run in the 0x01000000 address region.
If you list all the special requirements you can think of, we can make sure it supports them all.
However, having heard your latest request, I think we could redefine my 0xDFFFFFFF 99999999/77777777 to switch to that processor AND enable "emulator extensions" which would include access to 1xxxxxx on the ARM9.
Keep listing special requirements.
well if you do a code type instruction to access the arm9 cpu. is is a problem cause after a D2000000 00000000 which end the code you will have to re enter the DFFFFFFF 99999999 again such as a code that uses multiple pointers.
thats why i suggested doing a tic box under where the code is entered for every code that is enter individually.
and what do you mean by special requirements? like? weill it would make it possibly to edit any code in the game and use code types if ar had full access to all the ram.
who cares what happens after the code ends? I don't understand why we're talking about it. I don't understand why "you will have to re enter the DFFFFFFF 99999999 again" and I dont understnad "such as a code that uses multiple pointer" at all.
special requirements: what do YOU want?
simple really. full ar code support for arm9 cpu ram addresses. thats it.
Now that I think about it, I don't see why switching to arm9 wouldnt give you access to EVERY arm9 address, RAM, DTCM, registers, etc.
well, it used to. of course having it on arm9 permanently caused issues with pointer codes on some games. that why i said to make it optional
The whole premise here is making it optional. Keep up.
ok. well having this feature will make desmume unique as it will be the only emulator to have arm9 ar codes. hackers will like that they can work on any address location on the game with out limitation .
test latest build, I added the cheat code I discussed. But I didnt test it. A spot check to ensure nothing old was broken would probably not be needed, since a test of the new functionality for switching to arm9 will cover that as well.
AR still defaults to arm7
the normal AR reset command switches back to arm7, as it does reset everything
i just checked it it seems to be working fine.
heres a code the makes reverse and forward speed infinitely fast in mkds using the new code type.
the DFFFFFFF 99999999 code type is blocked by d200000 0000000 code type which is normal but thats where if a bunch of pointer are being used (BXXXXXXX 00000000) the DFFFFFFF 99999999 will have to be added every time a new pointer is made after a D2 and D1 and D0.
I will not do it that way. It is not more efficient, for these reasons, some of which I have already explained:
1. way more code on my end
2. less efficient for you: arm7 and arm9 codes cant be combined, and the setting must be conveyed to users
3. less efficient for users: arm7 and arm9 codes cant be combined, and users must get the setting, understand it, and remember to use it.
the D2 is a "full terminator". it's supposed to clear everything. D0 and D1 are not "full terminators" and do not clear everything.
The purpose of a "full terminator" is to glue two codes together. If the 2nd code is ARM9, then it should begin with the DFFFFFFF 99999999 command to indicate that it is an ARM9 code
hmmm... ok well what i mean was when that button was clicked both arm7 arm9 and DCIM or something like that could all be edited at once with in that code box.
But anyways it does work so far. ill further refine my testing later today is there anything specific you want me to test?
btw is DFFFFFFF 77777777 nessisary since it reverts back to arm7 after a D2?
Last edited by fintogive (2017-04-08 20:39:37)