Gecko dotNET Bugs and Requests

[Stuff]

Time for some bugs and requests.

bug: Only one I can think of atm, but this neeeeeds fixing. If you scroll down(+ to the memory address) in the memory viewer after going to a  new address, the visible address jumps to -0x60 of what it was. example, I put 902437C0 into the address box to go there, the visible address is 90243750, but if I scroll down, it jumps to 902436F0 and THEN I can scroll down just fine. It's retarded and bugs me out when I suddenly can't see what I was looking at until I scroll down a bit more. If I scroll up it worse. using the same example, it would jump up to 902436D0.

Not really a bug, it takes a while to start up. Is this why there's no more gct slowdown? >.<

request: Get ready for ridiculousness....I want Gecko.net to be extremely keyboard friendly. kb shortcuts all day. Shift+left/right through the tabs, alt+some letter to go to that tab. But then the idea gets stupid after that. Mem view and search results can get in the way, and it's just not possible to replace the mouse. After you said the F buttons in calc.exe switch through the different modes, I was like "oh ma gawd. There's liek no more reason to use the mouse in calc.exe. Imagine alt-tabbin through open windows just kb shortcutin with the ctrl-C, alt-tab, ctrl-V, +B18, enter, ctrl-C'in. XD. But oh noes. Gecko.net can't switch between tabs :o" And here I am.

[dcx2]

I'll take a look at the memview scrollbar thing.

I'm not sure why it would take a while to start up.  If you hold shift when you launch the app, it will start up without connecting to the USB Gecko.  My guess is that it's just a big app now and probably needs a splash screen to distract users while it's loading.

ctrl+tab, ctrl+shift+tab will switch through the tabs already.  =P  but I've been thinking about adding keyboard shortcuts for other stuff.  VS for instance uses F5 for run, and I think F11 for step into, shift+F11 for step out, F10 for step over.

Pretty much every button in calc has a shortcut.  Look at the help file for it.

[Bully@Wiiplaza]

same for me.
Pressing the scroll button at first, "teleports" to a different address (lower or higher) and from there, it keeps scrolling like normal.
Like Stuff said, it´s bugging people a bit...

[Deathwolf]

I wish there's an option for disabling the "debugger" info.... It shows me this info all the time after I click start searching. Actually, I had never any problems without Y.S. code which you included in Gecko dNET (I think you included it!? ). Codes like the File Patch Code should be an gct file. I even don't know why you need more free space? How many codes do you want to activate? Also WiiRd debugger don't use this code. I dunno how many codes you're activating via the USB Gecko but I still think it's not necessary. I don't want to be rude, I just think it not necessary at all. May I failed and there's already an option for this. If yes, so sorry for that.

[dcx2]

I don't understand what you mean by 'debugger info'.  You say searching, so that makes me wonder if you're using a code handler that I don't patch (Gecko OS Mod, or some old USB loader).  I think I have a message box that pops up when I can't patch the debugger.  I'll move the notification to a label in the Tools tab instead.

---

I dunno how many codes you're activating with via the USB Gecko but I still think it's not necessary.

Unfortunately, I do think the debugger patches are necessary.  Since the TX bug is particularly dangerous when doing searches, I make sure that the patches are there starting a search dump.  The patches fix multiple known bugs.  If you don't want the patches, don't use Gecko.NET.  They are that important.  Without the patches, you will experience bugs that have already been fixed.

If you don't believe me that the bugs are real, you can prove them to yourself.  Start any game.  Connect with WiiRDGUI.  Pause the game so the memory cannot change, and then do an unknown search.  Then keep doing equals searches; try at least seven equals searches in a row while paused.  Try to do stuff with your computer while it's searching (watch some YouTube videos or something).  You should always get 6,291,456 results for MEM1 or 13,631,488 for MEM2 (it doesn't dump all 64MB of MEM2 because IOS protects upper part of MEM2).  Keep equals searching for long enough, you'll start getting fewer and fewer results, even though the game is paused.  This is the TX bug.

Connecting Gecko.NET causes some code handlers to be patched.  You should be able to connect Gecko.NET, and then disconnect, and doing the search again with WiiRDGUI won't lose results (unless your code handler is old).  The latest versions of Gecko.NET put the patch's ASM at the very end of the code list (80002FC0 - 80003000) using hard-coded branches, so it shouldn't interfere with sending any other codes and it will be invisible to WiiRDGUI.

---

Regarding Y.S. extended codes, I think you are confused.  Extended code list is not forced on anyone.  You have to apply it yourself before Gecko.NET does anything.

There are two parts; the "allocator" which you are responsible for applying, and the "linker" which Gecko.NET will apply only if it detects the extended code list.  The 64 "linker" code is automatically applied only when there's a pointer in b0 (80001848).  It assumes the pointer in b0 is a pointer to the extended code list.  It will then automatically send all the cheats to the extended code list.  The 64 code will redirect the code handler to the extended code list.

It does not automatically apply the F6 "allocator" code, because that code needs to be applied before the game even starts.  There would be no point in automatically loading the code unless you connected to the game while you were in the Gecko OS loader, and I haven't implemented that feature yet.  If you do not apply the allocator yourself, you are not using the extended code list and it won't send the 64 code.

Why would you want extended codes?  Ask Stuff; he uses so many codes that they can't all fit when using the debugger.  brkirch would probably have liked to use the debugger to mess with the SMG2 Transformations code.  File patch code would have been easier to port with a debugger.  biolizard wanted to allocate a pad data object for his 6-player Smash Brothers thing, and the extended code list would give him enough room for that.  Y.S. had the overlay code.  You could even write a super complex hack in C, using the standard library and stuff like that, and you would now have 32k to fit your code into.  There are so many things that weren't even possible before.  And again...if you don't use the allocator, then Gecko.NET doesn't send the linker.

---

If Gecko.NET's patches bother you, just don't use it.  Don't get me wrong, I want people to use it, but these patches are required to fix bugs, so they aren't going away and they aren't optional.

I have more ideas for other patches; automatically patching the breakpoint beep out so you don't need to send the code yourself, and automatically freezing the Time Base register while the game is paused or breakpoint (this may have stopped some protections like the ones that caused your Metroid game to restart).  I'm also considering a feature to get all 64-bits from the float registers (did you even know they're actually 64-bits?), as well as the ability to write to the float regs.  There may also be a way to speed up searches that are specific, since they don't require comparing against a previous dump I can return just the addresses that match a specific value.

[Stuff]

Hmm. So that's what those fregisters are.

There may also be a way to speed up searches that are specific, since they don't require comparing against a previous dump I can return just the addresses that match a specific value.

o.O That would be epic.

Not all that important, but the thing that keeps track of the mouse's position in memview uses more cpu than anything else. Again, it's not important. I only noticed this because I connected the wii to my computer and was playing through media player classic. moving the mouse around the memory would make the video stutter. Everything else would, but not so much. I am using a very old PC, though. You probably wouldn't notice on any other computer. But if you were ever gonna do some performance improvements, that's the first place you want to check. lol.

[Bully@Wiiplaza]

complete agree to dcx2´s last paragraph.
These would be great.

Btw. can´t you finally include the F6 code I use that fixes a certain bug?
I need to manually send it from time to time.
It´s only 4 lines.

[Deathwolf]

Error: Could not apply debugger patches

Codehandler: Ocarina

Yup I see what you mean, I just wanted to say that.

If Gecko.NET's patches bother you, just don't use it.

Unfortunately, I have to use Gecko dNET... WiiRd freezes the game after a few seconds with "Auto-Update" on the Memory Vewer or during dumping files.

As I said, I wasn't sure about that all,

so sorry for that.

However, actually I was just asking about an option which disables this Error message... or is it only me who get this error?
Why I'm using Ocarina? Because the laser just died while playing for NO REASON. I'm almost afraid for these Japan lasers from wii's. So I bought a new wii only for USB LOADER .Shit happened, that's why I hate discs. Anyway, this is offtopic.

Error:
http://imageshack.us/photo/my-images/571/unbenanntpdj.png/

You don't have to fix anything. Just want to say that.

[Bully@Wiiplaza]

Bug on (Wiiware Game: Texas Hold´em Poker)

Sending C2 codes (I also used the correct undo line above it) crashes, even when the instruction is not executing at that time.
It then says: "Wii Exception caught, switch to breakpoints tab!"
It´s also the first time to send a code after booting the game.

3.) Here´s the function:

[spoiler]  CR:24000400  XER:00000000  CTR:00000000 DSIS:06000000
DAR:00006814 SRR0:80001DEC SRR1:00003032   LR:80002FF0
 r0:800A9A44   r1:807C0DD8   r2:8041D960   r3:D0000000
 r4:00000001   r5:00000000   r6:80000000   r7:80001808
 r8:00000000   r9:005DB3E0  r10:80001EF0  r11:FFFFFFFF
r12:80001D44  r13:8041AE00  r14:00001800  r15:80002988
r16:08400000  r17:00001800  r18:8000283C  r19:00000002
r20:CC000000  r21:00000000  r22:80002988  r23:00000000
r24:00000000  r25:00001032  r26:00003032  r27:80002980
r28:000000FF  r29:00000040  r30:80002FA4  r31:80000000

 f0:3F800000   f1:3F800000   f2:3F800000   f3:00000000
 f4:00000000   f5:3F800000   f6:43A00000   f7:43A00000
 f8:C382C294   f9:4B800000  f10:3F800000  f11:BB088889
f12:3ACCCCCD  f13:00000000  f14:00000000  f15:00000000
f16:00000000  f17:00000000  f18:00000000  f19:00000000
f20:00000000  f21:00000000  f22:00000000  f23:00000000
f24:00000000  f25:00000000  f26:00000000  f27:00000000
f28:00000000  f29:00000000  f30:00000000  f31:00000000

80001DEC:  92F86814   stw   r23,26644(r24)
80001DF0:  90786824   stw   r3,26660(r24)
80001DF4:  92D86820   stw   r22,26656(r24)
80001DF8:  80B86820   lwz   r5,26656(r24)
80001DFC:  70A50001   andi.   r5,r5,1
80001E00:  4082FFF8   bne+   0x80001df8
80001E04:  82186824   lwz   r16,26660(r24)
80001E08:  90B86814   stw   r5,26644(r24)
80001E0C:  4E800020   blr   
[/spoiler]
Seems not to be my fault, since this same function popped up on any C2 code (I tried with 3 different ones)
It´s clearly a bug.

I used gecko.net 0.66.7 plus gecko OS 1.9.3.2

Older gecko.net versions work fine and don´t have that freeze.
Code(s) work.
I tried with built r93.

Hope you can fix it, dcx2.
Thx

[dcx2]

@Stuff - yeah, the MouseMove event for MemView probably eats up a lot of cycles when the mouse is moving through it.  That's what auto-calculates the address under the cursor.  Not much I can do, because this is needed to be able to easily set breakpoints on non-word aligned addresses.

@Deathwolf - yes, I will get rid of the "could not apply debugger patches" message box.  It will instead be a label on the Tools tab.  But if you have to use a USB loader because of your dead laser, I recommend cfg usb.  From what I hear, it uses the 1931 code handler, which means you'll have F2/F4/F6 codes as well as the debugger patches.

I'm also considering an app that lets you splice your own code handler into the .dol of almost any loader app.  That way you can update apps that use the old code handler (e.g. Gecko OS Mod) to use a new code handler, or even a custom code handler that I might release which is pre-patched.

@Bully - hmmm, that's odd.  It crashed on checkexisend.  Did the message box alerting you to the crash bother you?  I was considering making it more prominent so that any time it happened while you weren't waiting on a breakpoint, it would notify you.  Or maybe even auto-switch to the BP tab and get the crash data.  Would that be too invasive?

You can go to disasm tab, 80001914:  3AA00000   li   r21,0   (for 1932), and Set SRR0 and then hit Run.  That *should* recover from the error, but I don't know why it even happened.  It looks like the kinda thing that one of the debugger patches is supposed to fix.

Note that with 1932, you don't need Undo codes for C2, just 04 ASM patches.  1932 keeps an "unhook list" after the code list.

Have you tried sending non-C2 codes?  Have you tried sending no codes?  Have you tried sending codes with undo disabled?  Have you tried Gecko OS 1931?

I think this is due to exisendbyteAA flushing...it fixed problems with memview crashing the game, but now it might make codes crash the game...looking at the LR, it's 80002FF0, which is where I put my debugger patches.  But that is the rx patch, and not the AA patch.  The message to switch tabs would only appear *before* the codes are actually sent.  If it is the AA flushing then 0.66.6 wouldn't have that problem.

I'll have to look into this when I get some time.  It might not be in the next build, because first I want to push one that has the scrollbar fixed and moves the "unpatched debugger" notification to the Tools tab.  Depends on how much time I have.

[Bully@Wiiplaza]

You can go to disasm tab, 80001914:  3AA00000   li   r21,0   (for 1932), and Set SRR0 and then hit Run.  That *should* recover from the error, but I don't know why it even happened.

Yes it recovers with 0.66.7 (but older gecko.net versions freeze up instead) lol ;D
I tried sending the C2 code without the undo line, same crash.
Gecko.net version 0.66.5 -> same thing happens, crash.

---
Wow, it also crashes on a useless 04 RAM Write with same value like the one in RAM...
On GCT Tab, it says that there are 192 codeslines available, just as a side note.

It even crashes when I send an empty codeslist xDDD

Damn, I need to put this game aside for now, it´s just horrible to hack with those sending bugs >.<

[Stuff]

mousemove: Alright. Like I said, it's not a big deal. It was only noticeable when the cpu was at it's limit. I was gonna ask about the click/right click event or even just doing it in the gotobreakpoint()(you know), BUT then I'll miss the little address thing in the upper left corner. If it ain't broke, don't fix it. :p

msg boxes: The msg boxes are important for errors/exceptions/all that. The switch to bp tab thing is a good idea, just make the msg box pop up and ask if you want to go there(haven't seen it myself so, sorry if it already does this). Reasons I would like to stay in the current tab can vary...usually something that can be done later, but just switching to the bp tab with no notification is like "wtf >.>". Yes, msg boxes are inconvenient, but would you rather it keep it to itself/have the msg hidden somewhere?

For the unpatched codehandler I was leaning against removing the msg box, but putting that in the tools tab brought up a better idea. Put it in the status bar. Right there where every other msg you hardly ever look at is at. if (connected && code handler unpatched) then status = "your codehandler sucks :p" So instead of "transfer completed"(I think that's what's always there), you can see that your codehandler sucks. Because it's more of a status than a...whatever you planned to do with it in tools.

I use cfg usbloader when I'm too lazy to change the disc and I also like it's 'manage cheats' option. But yeah, if not 1931, it has some bootleg code handler that's similar and I never get that status msg. Just somethings don't work properly. Unfortunately, the extended codelist is one of those things. >.< He needs to fix that hook without cheats thing though >.>

[dcx2]

@Bully - good to hear that it's recoverable.  I think I know how to fix this issue then.

Like I said before, the msgbox pops up before the actual codes are sent.  It goes something like this.

1) Send a byte to the code handler that says "prepare for cheats"
2) Code handler replies "AA" = Acknowledged
3) Gecko.NET turns all the codes into a cheat.bin, and sends the bin to the code handler.

If you get the msgbox, then 2) failed and instead you got "11" = breakpoint.  So your cheats were never even sent - it crashed before that, and would crash even with an empty codelist.  The AA thing also happens with dumping for searches, memview, registers, disasm etc so there must be something different about how 1932 is sending cheats (I almost always use 1931 handler so I would have seen this earlier).

I'm now considering a feature that detects code-handler crashes and automatically sets SRR0 to the right place to recover from it.  Perhaps with msgbox "crash detected in code handler!  Reset SRR0?  yes/no"

Could you try again with 1931 to confirm it's a problem common to both code handlers?

---

@Stuff - Perhaps I could do a hybrid approach.  Do it in the click event, and also have a "refresh timer" so that the address marker updates at, like, 10 Hz or something reasonably quick.  But yeah, ain't broke don't fix at least for now.  I've been meaning to make the watch list use a timer instead of a thread (because the watchlist is bootleg)

Yeah, I think I'll do a msgbox "crash detected!  Switch to BP tab?  yes/no".  If yes, it will also automatically grab the disasm and regs.  Maybe even some extra feedback by automatically parsing SRR1 to determine what type of exception.

I see what you mean about putting it in status, but I actually would like to try to use that more often for its intended purpose.  Besides, there's already a label on the tools tab that tells you whether your USB Gecko driver is good or needs updated.  If it needs updated, I even provide a link to the FTDI page for the driver.  ^_^

So that's why I was considering putting it there.  Just a label "handler: " and then 1931, 1932, GOM, or ???  That way, when someone has a problem, I say "go to Tools tab and tell me what version of the handler you're using".  Instead of trying to figure out which various loader version x.y bz has what handler.

[Bully@Wiiplaza]

It does not happen on gecko OS 1.9.3.1 :o

[Deathwolf]

Some random crashes while sending codes.
http://imageshack.us/photo/my-images/805/unbenanntfxy.png/

FTDIUSBGecko.EUSBGeckoExeption

Codehandler: Ocarina