oh its just the shift key? i thought Rshift was R + shift not the right shift key lol. ok nevermind...
i used the full version of (BOOBOO) posted above which worked fine.
I made some throw away codes to test in an empty part of the ram at 020000dxx. for mkds
the first 8 bits aren't correct and the last bit is 00 when it should be 12
pressing select should move the value up on the address 0x02000d70. but doesn't work
this should copy 18 bits from the address 0x02000000 to the address 0x02000df0 but it doesn't do anything.
Last edited by fintogive (2016-12-04 03:12:04)
Thanks!! those are excellent testing codes.
1. OK, fixed Ex codes (was copying from 1 word too early in cheats)
2. OK, this was caused by <v1.54 lameness--offset gets set to a weird value when executing code DB. As planned, I changed the code to use all v1.54+ logic, which fixed that weirdness, leaving offset at 0 as intended
2b. Also coincidentally, there was another bug in code DB which made it write 16bits instead of 8bits
3. OK, fixed Fx codes (was a complete cock-up)
Awesome! I don't think ive ever seen you use an exclamation point before in your post let alone 2 of them
And no problem! once that build is compiled to desmume nightly builds ill check it and further refine checking the cheat engine for further bugs. i think i pointed out all the major stuff so ill try combos and other codes types next.
this things i haven't checked is
3 less than
4 greater than
5 equal 2
d5 set value (never found a use for this code type since its so simlar to 0 1 and 2)
d1 which is similar to d0 except i think it ends repeat values if i remember correctly.
d1 is pretty much useless on desmume since there no slow down when using a lot of codes like action replay had.
btw what codes were you using when you said only 20% was working?
I was trying a bunch of mario kart codes.
like i know i tried 'always be shyguy' and 'start from the final lap'
http://www.neoseeker.com/mario-kart-ds/ … replay/ds/
But it's always been 20% for me.
I know I always tell people cheating takes brains. Maybe there's some secret I dont know. But that's my point. I'm not an expert--I contend you need to be. Do you dispute that? Is it supposed to be easy?
D1 may be useless on desmume, but there should be plenty of cheats out there made for real ARDS hardware which use it, right? Yeah I know they can be fixed to not use D1--who wants to do that?
ok i thoroughly tested everything i could. everything seems to be in order i did find a possible issue with 7xxxxxxx yyyyzzzz (16 bit greater than) on the masking end (yyyy)
it doesn't respond to any value i set the test code to.
when inactive this code makes the sub map zoom way out. when active the sub map will look normal
if the the value is greater than on this code here 02000E00 00000004 the code above should exude.
but it doesn't do anything no matter the value.
the only other thing is the F copy code should be able to use it with B and DC too but ive never used F with in a pointer. it didnt work when i tried to make a code to use in a pointer and im out of town so i cant check on a real ar device.
it used to work fine on softrasterizer in desmume 9.7 but not this version.
Last edited by fintogive (2016-12-05 08:55:50)
Sorry, I dont understand this. how can an inactive code have an effect? I can't see any effect with that code no matter what I do when testing 0.9.11
I don't fully understand the involvement of "02000E00 00000004" either. I guess you're trying to tell me the 4-line code reads 02000E00? But what's the significant of the 4?
It looks like your "72000E00 FFF30000" is nonsense. That says "if 0 > [2000e00]&stuff". 0 can never be greater than the stuff on the right hand side, unless those comparisons are supposed to be signed. By changing that cheat to "72000E00 FFF30001" I can make it functional (by ensuring [2000e00] is equal to 0).
But.. I needed to fix a couple of bugs in the masking. Perhaps you encountered those bugs and your test case written here is just garbled.
Based on my inspection, the F copy code uses the offset (controlled by a B or a DC). I don't know what "with in a pointer" means. B is pretty tricky to use (D3 which you have previously tested and DC are far easier) but not hard to implement in the code.
Last edited by zeromus (2016-12-06 03:25:05)
Ah ok well its not a big deal ive only seen masking used with a greater than code type masking to utilize an address on the ds that doesn't work the same on desmume speaking of doesn't work the same on the address 0x04000134 there should be a button activator for the touch screen. but there's no response from that address when the touch screen is pressed on. im guessing it doesn't work the same on desmume.
the code above should work like this
second line from the code is set to 3 on masking
that code should become active when this address 02000E00 00000004 is set to 4 or above and should be inactive when set to 3 or below. but it doesnt do that.
As for the F code type ill be able to find out more once i get home to check on the real ar device
Uhhhh, nope, I dont get it. Masking isnt relevant. The mask is applied to the value that's read from memory--which doesnt matter because your code is passing if 0 > (some value) and there's no such value that's true for (unless it's a signed test--and i've seen no evidence of that)
See, here's the formula
IF YYYY > ((not ZZZZ) AND half[XXXXXXX])
in case the value is 0, we have:
IF 0000 > ((not FFF3) AND 0) -> IF 0000 > (000C AND 0) -> IF 0000 > 0 (false)
in case the value is 4, we have:
IF 0000 > ((not FFF3) AND 4) -> IF 0000 > (000C AND 4) -> IF 0000 > 4 (false)
I think you meant to use an 0x08 code.
I just made a commit which should fix the 0x04000134 activator. That isn't a cheat bug but a basic emulation bug.
ah ok well like i said im not home ill check the code with a real ar if it works the same its correct. and thanks for the commit to fix that bug. when i said the code utilized an address. it was this address
04000100 or 74000100 FF000000
the address value is in constant motion on the hardware. on desmume this address is always at 00000000.
so question. what were the bugs with masking? you said there were some?
The bug with masking was hard to describe. Just forget it. Those cheat codes were totally broken (but I fixed them).
04000100 is broken due to other bugs in the emulator (there are lots of bugs like that one. it will take many hours of work to come up with a solution to systematically fix them all).
But I just fixed those (hopefully). Most arm7 programs read 16bits from the timer registers but your cheat codes read 32bits (which wasnt supported)
alright. cool. well it appears rogerman fixed the graphical issue above. ill wait for the next build to test.
and since were on the code topic remember the topic i posted about getting the dissesembler "world class" quality? im still holding my breath that it gets an over haul but have to cheat a few thousand time wile holding it
there is a glitch with the disassembler that causes it to basically freeze randomly but the rest of desmume continues to work fine. so once all this is done with the cheat engin could the disassembler be improved?
sorry, it's never going to be world class quality. I won't work on that.
hmmm ok. sounds like its a cluster f*** to work on.
It's redundant. Debug in nocash.
just checked the new build git#36b192a
the address 04000100 is working now but the touch screen button activator at the address 0x04000134 still isnt working the address value is 00000000. masking on the 7 code type is still broken. when i get home ill verify how the masking is suppose to work (since it been awhile since i last used an real action replay)
Err.. i fixed 0x4000136. I assumed that's what you meant. But I forgot you were using an 0x07 code which does truly only read 0x4000134 and 0x4000135.
Don't use 0x4000134. That's nuts. That's some kind of transient serial IO traffic. I don't see how you can figure out ANYTHING about a touchscreen from that. It will only be active if the firmware is running and actually running the touchscreen by communicating over the serial line. Without a firmware running, that doesnt happen.
Use 0x4000136 instead.
the 7 code type is a separate issue. anyways i should have been more specific, 04000134 is the base address, 04000136 holds the touch screen button activator on ds hardware. and what do you mean a IO traffic? on any ds the touch screen address is 04000136.
so wait a sec. i need a ds firmware to activate the touch screen address?
Well, I insist I fixed 4000136. Post a non-working cheat code that proves otherwise.
No, you need ds firmware to activate 4000134 which contains random noise. 4000136 contains the touch screen flag. If you read that by reading 4000134, then that's great, I dont care.
indeed you have fix it. that is so weird... i just tried a code that uses a touch screen button activator and it works but the value changes doesn't show up on the memory viewer. it shows up as 0000
because like i said, 4000134 is not emulated. 4000136 is -- and it's definitely not 0000.
If you're reading a word-sized value out of 4000134 then you get 4000136 along with it.
ok, well it works. thats all that matters. so nothing will show up on 04000136?
Last edited by fintogive (2016-12-10 00:43:11)
like i said, 4000134 is not emulated. 4000136 is
Just wanted to update you. everything is working good. i check the remaining issues on a real AR device and the codes respond the same. so i think the AR cheat engine is 100% operational now
ill report back if i find anything else though.
Great, thanks for checking it thoroughly