Gecko.NET is now hosted on Google Code!
Current version: 0.65
Bugs Reports/Feature Requests go here ---> http://wiird.l0nk.org/forum/index.php/topic,4954.new.html#new (and/or Google Code (http://code.google.com/p/geckowii/issues/list))
Download Experimental ---> http://wiird.l0nk.org/forum/index.php/topic,4886.new.html#new (http://wiird.l0nk.org/forum/index.php/topic,4886.new.html#new)
Download Latest Stable ---> http://geckowii.googlecode.com/files/Gecko dNet 0.65.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.zip)
Browse the Source ---> http://code.google.com/p/geckowii/source/browse/
Note! Source is outdated. I need to merge a few different sets of changes together and I want to make sure I don't mess anything up before I commit the changes.
---
Release notes:
Gecko.NET 0.65
http://geckowii.googlecode.com/files/Gecko dNet 0.65.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.zip)
---
General changes since 0.64:
- Automatically patch the code handler for Gecko OS 1.9.3.1 and 1.9.3.2 to increase stability and accuracy.
- Major changes to USB Gecko interface; improved transfer speeds
- General bug fixes
- GCT Code Undo
- Copy All Frames; will put the whole call stack, disassembly, and registers into the clipboard
- Pointer Search tab using Dr. Pepper's Pointer Search app
- Reload old search, even after closing and re-opening Gecko.NET
- Breakpoint Condition: Value of Address
- BP tab disassembler can scroll back a few instructions now
- Shift click a Memory Viewer cell to add it to the MemView Hex Search (good when searching for F6 code "unique values")
- Integrated ASMWiiRD and PyiiASMH support
- Auto Capture screenshots
- Single Frame preview
- Faster watch list
---
For detailed release notes, go to a given link and read the notes for each version and sub-version
0.65 http://wiird.l0nk.org/forum/index.php/topic,4886.msg68576.html#msg68576 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg68576.html#msg68576)
0.64 http://wiird.l0nk.org/forum/index.php/topic,4886.msg67325.html#msg67325 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg67325.html#msg67325)
0.63 http://wiird.l0nk.org/forum/index.php/topic,4886.msg58943.html#msg58943 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg58943.html#msg58943)
0.62 http://wiird.l0nk.org/forum/index.php/topic,4886.msg53436.html#msg53436 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg53436.html#msg53436)
0.61 http://wiird.l0nk.org/forum/index.php/topic,4886.msg46432.html#msg46432 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg46432.html#msg46432)
0.60 http://wiird.l0nk.org/forum/index.php/topic,4886.msg45895.html#msg45895 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg45895.html#msg45895)
0.51 http://wiird.l0nk.org/forum/index.php/topic,4886.msg45389.html#msg45389 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg45389.html#msg45389)
----
Screenshots are (outdated) at: http://l0nk.org/g.net/
No pointer search and dumbed down breakpoint tab? I'll pass
Quote from: wiiztec on January 03, 2010, 02:02:16 PM
No pointer search and dumbed down breakpoint tab? I'll pass
READ THE README!!!!!!!!!a) If you look at the readme.. I clearly pointed out why pointer search is NOT GOING to be a part of it.. if it comes.. it will be an external application for good reasons. Internal pointer search has the following disadvantages:
1) WiiRd locks up.. you can't do other searches.. the program is essentially blocked especially when you do pointer in pointer searches
2) If your Wii is not running.. even if you have the dumps then you can't do searches although there is literally no reason why it should.. as you do not need any Wii connection for the pointer search
b) Breakpoint tab: look at the instruction: it is easy to implement the features which are currently dopped.. in fact: at core level they even exist.. I just TEMPORARILY did not add them as I for myself haven't really used them yet.. if you think they are required.. they will come back
c) Have you ever heard the term BETA?
I need beta tests. Is it stable? Are the features in there working.. I won't add functionality unless all other functionality works!
Many thanks for providing us with this new tool and for sharing the source codes as well. I will try to use this (in addition to wiird GUI) and let you know if I have any feedback or questions.
Cheers.
After looking in the source, it looks like libftdi isn't fully implemented yet; I'm fine with waiting for it though, as long as the Linux version becomes available in the future. Too bad C# isn't my language of choice, otherwise I'd try and implement it completely myself.
Still, nice work and I hope to see more releases too. :)
Quote from: Link on January 03, 2010, 02:09:45 PM
Quote from: wiiztec on January 03, 2010, 02:02:16 PM
No pointer search and dumbed down breakpoint tab? I'll pass
READ THE README!!!!!!!!!
a) If you look at the readme.. I clearly pointed out why pointer search is NOT GOING to be a part of it.. if it comes.. it will be an external application for good reasons. Internal pointer search has the following disadvantages:
1) WiiRd locks up.. you can't do other searches.. the program is essentially blocked especially when you do pointer in pointer searches
2) If your Wii is not running.. even if you have the dumps then you can't do searches although there is literally no reason why it should.. as you do not need any Wii connection for the pointer search
b) Breakpoint tab: look at the instruction: it is easy to implement the features which are currently dopped.. in fact: at core level they even exist.. I just TEMPORARILY did not add them as I for myself haven't really used them yet.. if you think they are required.. they will come back
c) Have you ever heard the term BETA?
I need beta tests. Is it stable? Are the features in there working.. I won't add functionality unless all other functionality works!
I have no need for other searches while I'm doing a pointer search what I do have need for is reduced clutter and having a seperate poiner search application adds to that problem
reducing clutter is not always most efficient...
suit yourself. I still love you Link :D GeckodotNET is way better in my opinion already (despite still being in beta) and it only has a few issues left so its all good. The things it does include make up so much more and compensate for everything it lost (which really isn't gone).
yeah thanks for your efforts Link
Is it possible to comment out individual lines of codes like wiird used to do?
At the moment a code is on or off via the check-box, i cant disable certain lines of the code
ta
Quote from: Panda On Smack on January 04, 2010, 10:56:52 AM
yeah thanks for your efforts Link
Is it possible to comment out individual lines of codes like wiird used to do?
At the moment a code is on or off via the check-box, i cant disable certain lines of the code
ta
Admittedly, no that's not possible yet, I have certain troubles with .NET components so far when it would come to such a feature.. I am trying to do something like that though.. would you be happy enough if I made it with a commenting system like you proposed:
meaning:
01234567 89ABCDEF <-- active code
- 01234567 89ABCDEF <-- inactive (notice the minus!)
that would be simple to make and might serve the purpose already!
yeah perfect
maybe keep the standard JS/C# way and use // to comment out a line?
e.g.
20214378 00000300
048FD8DC 00000000
// CC000000 00000000
// 048FD8DC 00000001
E0000000 80008000
Or a string the user specifies? :D
Or just a dropdown-box with some predefined comment strings.
Or any character that is not 0-9 A-F.
Just my thoughts :P
Well, I checked its sources.. its code input parser is well.. written to be ultra-fair.. meaning: no matter how you enter the codes it will always extract only 0-9 and A-F sequences and checks if it collected an amount which is a multiple of 8.. so I can easily add other signs..
What I'll do: when you type in - or / within a code - then it will mean that the line it is in is deactivated.. when you click a code again.. it will most likely use the // syntax to demonstrate a deactivated line.. but yeah when entering codes.. it's very polite and basically accepts everything!
nice one mate
I think it's great! I will certainly be using this next time I hack! =)
Much appreciated, Link!
Best Christmas gift ever!
Quote from: Zetta_X on January 11, 2010, 05:46:08 PM
Best Christmas gift ever!
Yup and nearly 12 months early :D
On a side note, has this been changed at all since the last revision?
It keeps freezing if I leave it on my computer unattended for over an hour or so... It's kinda annoying :P
re-direction post to bugs in WiiRd GUI and in Gecko Dotnet/Suggestions. Click Here (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html).
or Here (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html)
or even Here (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html)
hi (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html)
If our previous main tool was wiird and upcame the website wiird.l0nk.org,
Our new tool is gecko dotnet, is this going to be gecko.net???!?!
/noob post
Fun stuff
Quote from: Zetta_X on January 23, 2010, 01:15:51 AM
If our previous main tool was wiird and upcame the website wiird.l0nk.org,
Our new tool is gecko dotnet, is this going to be gecko.net???!?!
/noob post
Fun stuff
I was thinking the same lol
not a noob post :)
Thank you Link for gecko dotnet :)
I have a game which wiird froze on gecko dotnet works perfectley.
Thank you :)
Quote from: Zetta_X on January 23, 2010, 01:15:51 AM
If our previous main tool was wiird and upcame the website wiird.l0nk.org,
Our new tool is gecko dotnet, is this going to be gecko.net???!?!
/noob post
Fun stuff
WiiRD is still better IMO
Quote from: wiiztec on January 23, 2010, 05:09:08 AM
Quote from: Zetta_X on January 23, 2010, 01:15:51 AM
If our previous main tool was wiird and upcame the website wiird.l0nk.org,
Our new tool is gecko dotnet, is this going to be gecko.net???!?!
/noob post
Fun stuff
WiiRD is still better IMO
Same here, if It didn't crash as much for me. :confused:
Quote from: wiiztec on January 23, 2010, 05:09:08 AM
WiiRD is still better IMO
Link has put a lot of effort into this so while that may be your opinion I don't think we need to start expressing what we prefer in this thread.
I felt I needed to say something when somebody was talking about changing the identity of the site because Gecko.net was now the "main tool" when a lot of people still use WiiRD
I wonder if I should buy Gecko.net and just re-direct to this website. :):D:confused:
There are quite a few bugs for me.. basically Gecko dotNET was my decision of writing as on all my 3 PCs I have here (Netbook, Desktop and Media Center) I switched to Windows 7 64 bit (except Netbook which has 32 bit).. while on the Netbook WiiRd still runs quite fine on my Media Center and my Desktop with 64 bit Windows.. it randomly crashes every 5 minutes..
For the crashing of Gecko dotNET - I have no real idea on my stations it ran quite stable however as mentioned: I do not have any XP machines anymore, I switched completely from XP to 7 so I wouldn't doubt if problems occur on XP. Basically I really would like to continue but right now.. well, my time table has been a little mean to me (work, work, work).. and no enhancements in sight (see my current forum activity it is close to 0). Even in the winter vacancies where I expected to find some time, I was overly busy :(
For the 1 hour lock-up hetoan mentioned.. I admit I never left it running such a long time.. it's a little strange that this happens because unlike WiiRd when you leave it unattended Gecko dotNET shouldn't send or receive anything from the Wii except given the fact you're in the watchlist tab - so: do you use it in the Watchlist - what happens if you disconnect it from the Wii and then leave it unattended (really: WiiRd GUI has 6 timers which randomly receive and send data, Gecko dotNET has none it should not do anything without your command - maybe .NET is acting up)? I will look into it though (I'll just put it on my netbook and leave it running there - my netbook is weak as hell when it comes to PC power it should lock up quickly enough on that one).
I really, really hope to find some time to work on this again.. right now I have work off again (I work 4 week shifts and then I have 2 weeks of job school) - I have school beginning on Monday and school admittedly has been a lot fairer when it comes to my time table (work begins at 6 to 7 AM in the morning and I am free to leave between 3 and 4 PM - yes I work on early shifts! - school: 8 to 9 AM to 1 or 3 PM depending on lessons) - with one difference: school has some homework and exams but well.. things shouldn't be too hard!
Additionally I plan to document the code more which is one of my priorities.. as planned, gecko dotNET will be open-source and GPLed so any enhancements by other developers are CLEARLY welcome (what does GPL say: you may modify my code to any extent as long as you also release the source code - and yes for closed-source modifications I will react with anger!).
For the WiiRd GUI, did it ever lock-up on you? I'm running Windows 7 32 bit, and the WiiRd GUI is what locks up all the time. I'm always using gecko dotNet, and it hasn't locked up on me yet. I think I have left it running for more than one hour. Also, the only bugs I have found I have made a topic (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html). Click Here (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html). Other than that, there isn't really anything wrong with it. If you coded it in Windows 7, then it could be the .Net Framework (mabye).
I had nothing to do so I made an fix for your first request, so if Link adds this to Gecko.NET you should have a next button when the game is paused. (or if Link has a better solution, that would be even better :P )
private void PGame_Click(object sender, EventArgs e)
{
if (gecko.status() == WiiStatus.Running)
{
gecko.Pause();
PGame.Text = "Next";
}
else
{
gecko.Resume();
nextTimer.Interval = 100; //user specified?
nextTimer.Enabled = true;
}
}
private void RGame_Click(object sender, EventArgs e)
{
gecko.Resume();
PGame.Text = "Pause game";
nextTimer.Enabled = false;
}
private void nextTimer_Tick(object sender, EventArgs e) //Add a timer to the MainForm called nextTimer
{
gecko.Pause();
nextTimer.Enabled = false;
}
This should have the same result as the next button in WiiRD
BTW I just tried opening the FST of Wario Ware Smooth Moves in Gecko.NET and it froze (game froze and Gecko.NET staid at 0%), then I tried it in WiiRD and it worked, then in Gecko.NET again and it froze again.
Quote from: Mal1t1a on January 24, 2010, 04:32:37 PM
For the WiiRd GUI, did it ever lock-up on you? I'm running Windows 7 32 bit, and the WiiRd GUI is what locks up all the time. I'm always using gecko dotNet, and it hasn't locked up on me yet. I think I have left it running for more than one hour. Also, the only bugs I have found I have made a topic (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html). Click Here (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html). Other than that, there isn't really anything wrong with it. If you coded it in Windows 7, then it could be the .Net Framework (mabye).
WiiRd GUI certainly locks up all the time on Vista and 7.. WiiRd GUI is based on GCNrd GUI which was written with Windows 98 in mind back in 2001.. and well.. WiiRd originally was even developed in Delphi 6 but the Delphi 6 compiles just completely didn't work on Vista x64 (I assume they wouldn't work on 7 x64 either).. thus the code was ported to Delphi 2006 which compiles and runs fine on Windows Vista x64 - however, the core is the same and it's still like 85% old GCNrd code and 15% WiiRd code.. the result is well.. instable on modern Vista and 7 platforms.. it's sad but yeah.. I would port the code properly however kenobi's code is more or less unreadable to me.. so I can only do very minor changes here and there but most of the suggestions for WiiRd - I'd simply be unable to perform them (believe me, I'd happily do!).
Gecko dotNET is a rewrite.. no code from the original WiiRd has been taken.. it is developed on Windows 7.. as Windows 7 and Windows Vista are very much alike I doubt Gecko dotNET will show any malfunctions on Vista.. as it is compiled against .NET 2.0 it should theoretically be backwards compatible until Windows 98 however, it was not tested on Win98 (I started it once and saw that it kinda works)! As it compiles against Mono on Linux I am happy but Linux users should accept that Linux is no real priority.. I do some compile checks here and there but year.. stable Linux ports will only come if the Windows version is finished and stable.. and I repeat: the Windows version was developed with Windows Vista and 7 in priority.. I did test it on Windows 2000 and XP.. it should run on them fine.. Windows 98 and ME work but they are certainly completely unsupported so if you use them.. please please switch!
Quote from: Romaap on January 24, 2010, 05:28:45 PM
**insert stuff here**
Is that C#? If it is, I think I'm switching from VB to C#. I would gladly help develop Gecko dotNet.
Quote from: Link on January 24, 2010, 05:59:03 PM
**Insert more stuff here**
If you were to write it completely for Windows 7/Vista, and just drop the support for everything else (this is just theory), would you be able to increase Search Speeds, and make it alot better than WiiRd GUI?
Quote from: Mal1t1a on January 24, 2010, 06:17:29 PM
Quote from: Romaap on January 24, 2010, 05:28:45 PM
**insert stuff here**
Is that C#? If it is, I think I'm switching from VB to C#. I would gladly help develop Gecko dotNet.
Yup, Gecko.NET is written in C#
Quote from: Mal1t1a on January 24, 2010, 06:17:29 PM
If you were to write it completely for Windows 7/Vista, and just drop the support for everything else (this is just theory), would you be able to increase Search Speeds, and make it alot better than WiiRd GUI?
lol, making it "alot better" - that depends on people's opinions.. I already got myself enemies because I will outsource pointer search.. and yes, this will happen, no pointer search in gecko dotNET.. for search speeds.. the biggest speed issue about searches is the dump speed.. WiiRd has an optimized block based dump.. I plan to develop something similar.. not just with fixed dump sizes but a little more varied (the idea is: it will only do dumps if the possible addresses follow each other in less than 256 Kilobytes of memory distance.. in WiiRd in worst cases it dumped 1 MB because of 2 addresses within this 1 MB block).. so if my theory on paper works it will be faster.. but those are just ideas..
Planned features certainly are:
1. Variable dump searches
2. Saving searches
3. Undo (will be linked to saving)
4. Conditional breakpoints
5. Deactivating certain lines in codes
6. A special dump format containing both dumps of 80 and 90 areas.. this would be used for the external pointer search application so that this one can search both areas at once (a major limitation in WiiRd right now)
Quote from: Link on January 24, 2010, 05:59:03 PM
Quote from: Mal1t1a on January 24, 2010, 04:32:37 PM
For the WiiRd GUI, did it ever lock-up on you? I'm running Windows 7 32 bit, and the WiiRd GUI is what locks up all the time. I'm always using gecko dotNet, and it hasn't locked up on me yet. I think I have left it running for more than one hour. Also, the only bugs I have found I have made a topic (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html). Click Here (http://wiird.l0nk.org/forum/index.php/topic,4954.0.html). Other than that, there isn't really anything wrong with it. If you coded it in Windows 7, then it could be the .Net Framework (mabye).
WiiRd GUI certainly locks up all the time on Vista and 7.. WiiRd GUI is based on GCNrd GUI which was written with Windows 98 in mind back in 2001.. and well.. WiiRd originally was even developed in Delphi 6 but the Delphi 6 compiles just completely didn't work on Vista x64 (I assume they wouldn't work on 7 x64 either).. thus the code was ported to Delphi 2006 which compiles and runs fine on Windows Vista x64 - however, the core is the same and it's still like 85% old GCNrd code and 15% WiiRd code.. the result is well.. instable on modern Vista and 7 platforms.. it's sad but yeah.. I would port the code properly however kenobi's code is more or less unreadable to me.. so I can only do very minor changes here and there but most of the suggestions for WiiRd - I'd simply be unable to perform them (believe me, I'd happily do!).
Gecko dotNET is a rewrite.. no code from the original WiiRd has been taken.. it is developed on Windows 7.. as Windows 7 and Windows Vista are very much alike I doubt Gecko dotNET will show any malfunctions on Vista.. as it is compiled against .NET 2.0 it should theoretically be backwards compatible until Windows 98 however, it was not tested on Win98 (I started it once and saw that it kinda works)! As it compiles against Mono on Linux I am happy but Linux users should accept that Linux is no real priority.. I do some compile checks here and there but year.. stable Linux ports will only come if the Windows version is finished and stable.. and I repeat: the Windows version was developed with Windows Vista and 7 in priority.. I did test it on Windows 2000 and XP.. it should run on them fine.. Windows 98 and ME work but they are certainly completely unsupported so if you use them.. please please switch!
Well that explains why WiiRd never locks up on me, I use XP
I used to have Windows XP and it froze like a million times.
I had two computers, I bought a nice gaming rig which happened to be Windows 7. Wiird would crash and freeze and not work all the time on gaming rig so I always proceeded to use my Windows XP laptop. The unfortunate part is it fell because someone tripped on the power cord and now I get an unmountable_boot volume error and the harddrive is fried, can't be read and toast. So I was basically at a disadvantage with wiird. I have used geckodotnet and it is working more than perfect for my current needs with games :)
Could you add the Save Searches function in a way that we will be able to save 10 (or more if you can!) per game?, just as you did with the notes stuff.
Also, could you make it so we can name the searches? Sometimes I don't know what is the search I'm looking for... :S
I'll appreciate it a lot! ;)
Quote from: Cory321 on February 01, 2010, 01:13:22 AM
Could you add the Save Searches function in a way that we will be able to save 10 (or more if you can!) per game?, just as you did with the notes stuff.
Also, could you make it so we can name the searches? Sometimes I don't know what is the search I'm looking for... :S
I'll appreciate it a lot! ;)
Saving searches is quite easy to add, and yes, I indeed do plan do add that feature!
Quote from: Link on February 01, 2010, 05:54:26 AM
Quote from: Cory321 on February 01, 2010, 01:13:22 AM
Could you add the Save Searches function in a way that we will be able to save 10 (or more if you can!) per game?, just as you did with the notes stuff.
Also, could you make it so we can name the searches? Sometimes I don't know what is the search I'm looking for... :S
I'll appreciate it a lot! ;)
Saving searches is quite easy to add, and yes, I indeed do plan do add that feature!
Looking promising :)
Does Geckodotnet have an automatic update feature or do we watch this space for new updates?
Well.. just to give you a status update.. Life kept me a bit busy but I finally was able to do some coding (no new beta yet)..
what has been implemented:
-code lines can be deactivated.. just add a "-" or "/" somewhere in the code and the line is parsed as deactivated.. when you select a code disabled lines start with "--" (pretty much like LUA comments)
-memory searches have got a block dump option.. this block dump was an idea I came up with today - it works totally different than the WiiRd one but it should be even more effecient.. this is what WiiRd do in comparison:
Split the range from the start to the end address into block of 1M in size... if values were found within this block the block gets dumped from its lowest value to its highest..
Worst case scenario: each block has exactly 2 results.. one very much at the beginning and one at the end.. WiiRd will end up dumping the complete block.
Gecko dotNET way: dynamic blocks! First of all it will ask the OS for memory (as large as begin of the dump to the end of the dump).. however it will only fill parts within it.. if two former results differ in distance by more than 128K (less than 128K would take long, as gecko dotNET always has to reinitialize dumps which would take time) they will be dumped seperately.. fact is that Gecko dotNET will create much more smaller blocks than WiiRd did.. the worst case scenario for gecko dotNET would be that all results are less than 128K next to each other.. it will only create one big block then (but WiiRd would more or less behave identically).
Result so far: very very fast search!
Awesome, thanks mate!
Quote from: wiiztec on January 23, 2010, 06:14:46 PM
I felt I needed to say something when somebody was talking about changing the identity of the site because Gecko.net was now the "main tool" when a lot of people still use WiiRD
What do you see being updated more often?
Gecko dotNET is still not the main tool, I think.. it will probably never be a replacement either as I'll never be able to 100% match up all of WiiRd's features.. so I wouldn't complain at all if they end up existing side by side (well, that's actually the plan)
Quote from: Link on February 07, 2010, 04:41:28 PM
Well.. just to give you a status update.. Life kept me a bit busy but I finally was able to do some coding (no new beta yet)..
what has been implemented:
-code lines can be deactivated.. just add a "-" or "/" somewhere in the code and the line is parsed as deactivated.. when you select a code disabled lines start with "--" (pretty much like LUA comments)
-memory searches have got a block dump option.. this block dump was an idea I came up with today - it works totally different than the WiiRd one but it should be even more effecient.. this is what WiiRd do in comparison:
Split the range from the start to the end address into block of 1M in size... if values were found within this block the block gets dumped from its lowest value to its highest..
Worst case scenario: each block has exactly 2 results.. one very much at the beginning and one at the end.. WiiRd will end up dumping the complete block.
Gecko dotNET way: dynamic blocks! First of all it will ask the OS for memory (as large as begin of the dump to the end of the dump).. however it will only fill parts within it.. if two former results differ in distance by more than 128K (less than 128K would take long, as gecko dotNET always has to reinitialize dumps which would take time) they will be dumped seperately.. fact is that Gecko dotNET will create much more smaller blocks than WiiRd did.. the worst case scenario for gecko dotNET would be that all results are less than 128K next to each other.. it will only create one big block then (but WiiRd would more or less behave identically).
Result so far: very very fast search!
Have you uploaded your latest build?
Not yet, so far there is one issue with the breakpoint tab (internal stuff, adding extensions for conditional breakpoints).. I'll doubt they'll make it in the GUI but I'll release a working build once that is fixed
I just tried Gecko dotNET with Pokemon Rumble (WiiWare) but it didn't load the game-id correct, so the NotePad and GCT didn't work.
My theory is that Gecko dotNET looks for the game-id in 0x80000000, but that only works for disc games, the game-id can also be found at 0x80001800 and that's the only place where the WiiWare game-id is.
Link, a feature that is useful in WiiRd is in the memory tab. You can search for a value and because it does it in small dumps my games don't 'time out' like they would do if I dumped all of the 80 range in one go
Is that possible to add?
Yeah, that feature was useful for some purposes.
I mainly used it to search for text, because you could just type what you were looking for instead of converting it all the time and it could search for more characters.
I'll have to see.. yes, why not, I guess, it's just difficult to add as the memory viewer tab is quite full.. I'll come up with something though!
Nice one
Why not just make the app bigger? Doesn't have to be same size as wiird
New features in version beta 0.4:
-block based search refining - VERY fast (outbeats WiiRd in most if not all situations)
-conditional breakpoints (please read readme: it is as powerful as the one in WiiRd it just looks completely different and far more "simplified" which it's not!)
-deactivating code lines
-readme added
\o/
I can't locate the Readme ??? Although, seeing as how the search is faster now, I'm already cheering deep inside before I get to test it out.
oops, forgot to add the readme.. I am not at home, I'll fix that later today when I am back
hmm, the source doesn't compile properly. When I compile it in C#, it error's out on this line: bpOutput.shortRegTextBox[i].Click += clickReg; in breakpoints.cs
The error is: Object reference not set to an instance of an object.
Also, the actual binary source, good-job with the VC Reading, it actually reads the name, but.... It still doesn't allow saving of names, it's over-reading the name or something. It's jsut not properly reading the name is all =) Still, great progress. =D
Quote from: Link on January 24, 2010, 04:04:44 PM
really: WiiRd GUI has 6 timers which randomly receive and send data, Gecko dotNET has none it should not do anything without your command - maybe .NET is acting up?
I've done mixed-mode programming (.NET and non-.NET in the same program). It's very dangerous to send and receive bytes across the managed interface. .NET has a Garbage Collector (GC) that runs periodically and has the right to re-arrange the heap! This is no problem for a managed program because .NET suspends all managed applications when it runs the GC and updates all the managed pointers, but any unmanaged pointers will be FUBAR after the GC runs. The FTDI driver is most definitely unmanaged, so any buffers that you're sending to the driver MUST be pinned! This can include any structures filled with configuration info. If you pin the buffers, the GC won't be allowed to move them around.
There are a few ways to pin. I think when the pointer is marshaled across to the unmanaged code, it is pinned, but I'm not sure this always works.
You can also use the fixed (http://msdn.microsoft.com/en-us/library/f58wzh21%28VS.80%29.aspx)() { } keyword. It will pin any parameters to fixed for the duration of the statement block.
Finally, there's a GCHandle (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.gchandle%28VS.80%29.aspx) class that you can use to pin objects.
I wonder.. there mostly are not any buffers I send to the Gecko (I receive and send byte arrays (void pointers in the original) ) which need to live longer than the function call.. the only variable is the handle ID which is a basic DWord (UInt32). If you like to check the file doing the complete communication with the D2XX driver is d2xxwrapper.cs - all other code in the project is managed.
Quote from: Link on February 16, 2010, 04:38:49 AM
there mostly are not any buffers I send to the Gecko (I receive and send byte arrays (void pointers in the original) ) which need to live longer than the function call
If those buffers are allocated by Managed code, then they will need to be pinned, although it's possible the managed wrapper class does the pinning. I'll take a look at the source when I get a chance.
Quotethe only variable is the handle ID which is a basic DWord (UInt32).
While an int is a "value-type" variable, it can be "boxed" into a "reference-type" if necessary, and it's not always entirely clear when this will happen. Once boxed, your int can be moved around like any other reference type.
BTW, you should use SafeFileHandle (http://msdn.microsoft.com/en-us/library/microsoft.win32.safehandles.safefilehandle%28VS.80%29.aspx) for handles instead of integers.
I'm finding that when I start refining searches after my initial search that Gecko dotNET is crashing and freezing my game. I can't reconnect and have to power down the Wii etc
ta
Quote from: Panda On Smack on February 23, 2010, 12:15:21 PM
I'm finding that when I start refining searches after my initial search that Gecko dotNET is crashing and freezing my game. I can't reconnect and have to power down the Wii etc
ta
Didn't happen for me, I'll happily check though, that of course shouldn't happen!
Quote from: Link on February 23, 2010, 05:50:33 PM
Quote from: Panda On Smack on February 23, 2010, 12:15:21 PM
I'm finding that when I start refining searches after my initial search that Gecko dotNET is crashing and freezing my game. I can't reconnect and have to power down the Wii etc
ta
Didn't happen for me, I'll happily check though, that of course shouldn't happen!
Hey Link, when you do your tests, do you use Debug or Release builds? Sometimes, the difference in optimizations can cause bugs to happen less often or not at all in Debug builds. For instance, debug builds allocate extra memory for arrays, so you're less likely to get errors if you fall off the edge of an array.
If I have no very special reason I do tests in Release mode.. I use debug mode only in certain cases
Hi Link,
I looked through the source code and I don't see anything that appears to pin the byte[]'s you're using in GeckoRead and GeckoWrite, so I modified them to pin their byte[]'s down in case the Garbage Collector decides to move the buffers while the driver is using them.
protected FTDICommand GeckoRead(Byte[] recbyte, UInt32 nobytes)
{
UInt32 bytes_read = 0;
GCHandle bufferPin = GCHandle.Alloc(recbyte, GCHandleType.Pinned);
FT_STATUS ftStatus = PFTDI.Read(recbyte, nobytes, ref bytes_read);
bufferPin.Free();
// etc
}
protected FTDICommand GeckoWrite(Byte[] sendbyte, Int32 nobytes)
{
UInt32 bytes_written = 0;
GCHandle bufferPin = GCHandle.Alloc(sendbyte, GCHandleType.Pinned);
FT_STATUS ftStatus = PFTDI.Write(sendbyte, nobytes, ref bytes_written);
bufferPin.Free();
// etc
}
If I were to continue with any more changes, what is the appropriate way to submit them to you?
Thx, it's okay, just to post the code, I included it.. for the SafeHandle thing.. I wasn't really able to figure that out as all of MS examples always expected to use Safehandle at function which would have a DWORD as output (DWORD File_open(params) ) and not where the DWORD is the result of a pointer ( DWORD Open_Ex(params, DWORD* handle) - other than that.. let's just hope that kinda fixes the known issues..
thanks though!
Yeah, the SafeHandle stuff is a bit confusing. But the good news is that unless the DWORD is being boxed, it's a value-type and not a reference-type, so it won't need to be pinned. I hope.
I am also having freeze when using unknown search, the initial search is fine
but the refine search sometimes freeze the game
http://l0nk.org/gdnb.zip
Version 0.41:
Changes:
-refining should be fixed (spotted the error)
-readme now included
-breakpoint fixes
-dec to hex buttons removed, context menu instead which also provides float to hex and such
-search within memory view added (non-functional yet, it's being prepared right now, the button won't do anything).
-under-the-hood-changes
Sources haven't been updated!
Thanks :D your effort is much appreciated.
Yeah, nice one Link
Hooray thank you!
Hi Link,
Whenever I try saving codes in GeckoDotNet I get an error. While I do not have my laptop with me, it gives me a giant paragraph and I believe the keywords (again I do not have my laptop to verify this) code handle exception error.
I am running Windows 7, 64 bit, home premium.
Thanks in advance,
Z
Does this only happen on WiiWare/VC?
Thanks for the update Link. Can't wait for the search in memviewer. Hopefully it's faster than WiiRD's :P
Hopefully in the future we can look forward to undo/redo search options and a function to export all the data you have in GeckoDotNET to a notepad.txt would be good too :D
Quote from: Romaap on March 02, 2010, 09:25:19 PM
Does this only happen on WiiWare/VC?
Good eye, it is only happening in VC/WiiWare. I remember that WiiWare and VC games have different organization of Title IDs not isomorphic to the structure of Wii games. That answers everything ;)
I just noticed that when you load WiiWare/VC the game id is shown but it is like this: (GAME
It is missing the )
So the game id might not be stored correctly thus causing an error when trying to save to a file with that broken name.
It's basically to do with the length of the game id
I just edited the source and changed it to loop through 4 characters instead of 6 and it works fine on a VC game
It errors on the 5th character as it doesn't exist
Saweet! Memory Viewer updates the FP value displayed when auto-updating! And you can click away from the memory viewer tab, that rocks too!
I added some requests. When you update the sources, I'll see if I can handle any of them.
EDIT:
Uh-oh! I got an ftdiusbgecko.eusbgeckoexception while I was trying to set/cancel a breakpoint.
Normally when I get an exception in a .NET app it shows something about the stack trace, but there was no trace, so that's all I have... =(
EDIT2: Got another one. =( Stack trace this time, woohoo! USBGecko.peek() gave up the ghost
************** Exception Text **************
FTDIUSBGecko.EUSBGeckoException: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown.
at FTDIUSBGecko.USBGecko.peek(UInt32 address)
at GeckoApp.MemoryViewer.CellSelectionChange(Object sender, EventArgs e)
at System.Windows.Forms.DataGridView.OnSelectionChanged(EventArgs e)
at System.Windows.Forms.DataGridView.FlushSelectionChanged()
at System.Windows.Forms.DataGridView.set_NoSelectionChangeCount(Int32 value)
at System.Windows.Forms.DataGridView.SetSelectedCellCoreInternal(Int32 columnIndex, Int32 rowIndex, Boolean selected)
at System.Windows.Forms.DataGridViewCell.set_Selected(Boolean value)
at GeckoApp.MemoryViewer.CellSelectionChange(Object sender, EventArgs e)
at System.Windows.Forms.DataGridView.OnSelectionChanged(EventArgs e)
at System.Windows.Forms.DataGridView.FlushSelectionChanged()
at System.Windows.Forms.DataGridView.set_NoSelectionChangeCount(Int32 value)
at System.Windows.Forms.DataGridView.ClearSelection(Int32 columnIndexException, Int32 rowIndexException, Boolean selectExceptionElement)
at System.Windows.Forms.DataGridView.SetAndSelectCurrentCellAddress(Int32 columnIndex, Int32 rowIndex, Boolean setAnchorCellAddress, Boolean validateCurrentCell, Boolean throughMouseClick, Boolean clearSelection, Boolean forceCurrentCellSelection)
at System.Windows.Forms.DataGridView.MakeFirstDisplayedCellCurrentCell(Boolean includeNewRow)
at System.Windows.Forms.DataGridView.OnRowCollectionChanged_PostNotification(Boolean recreateNewRow, Boolean allowSettingCurrentCell, CollectionChangeAction cca, DataGridViewRow dataGridViewRow, Int32 rowIndex)
at System.Windows.Forms.DataGridViewRowCollection.OnCollectionChanged_PostNotification(CollectionChangeAction cca, Int32 rowIndex, Int32 rowCount, DataGridViewRow dataGridViewRow, Boolean changeIsDeletion, Boolean changeIsInsertion, Boolean recreateNewRow, Point newCurrentCell)
at System.Windows.Forms.DataGridViewRowCollection.OnCollectionChanged(CollectionChangeEventArgs e, Int32 rowIndex, Int32 rowCount)
at System.Windows.Forms.DataGridViewRowCollection.AddCopiesPrivate(DataGridViewRow rowTemplate, DataGridViewElementStates rowTemplateState, Int32 count)
at System.Windows.Forms.DataGridViewRowCollection.Add(Int32 count)
at GeckoApp.MemoryViewer.Update()
at GeckoApp.MainForm.MemViewAutoUp_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.CheckBox.OnClick(EventArgs e)
at System.Windows.Forms.CheckBox.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
I'll most likely release a little update tomorrow..
For exceptions: I admit, I am very lousy on exception handling right now.. that will be changed later but so far I admit it isn't.. and certainly an exception just crashes the application as it does not handle it (only during the game start-up exceptions are handled).
For the current version: I changed some stuff in the FST tab (instant swap possible) and the ANSI/Unicode string search in the memory viewer is functional... other than that: just changed the notepad interface from the combobox interface it had to a tabbed interface!
Under USBGecko::Peek(), in the catch handler, you should throw up a messagebox that echoes the number passed into the EUSBGeckoException's constructor before re-throwing. Also, I don't think you need "throw e;" because I think you can re-throw the exception with just "throw;", no argument necessary.
The default .NET stack trace dump does not display any of the exception's arguments. Kudos on re-throwing the exception instead of swallowing it, though. That's good behavior. Better to bring the app down than leave it in an uncontrolled state.
EDIT:
Dump is definitely doing something naughty. I had MemoryViewer auto-update running and it caused Dump to crash. However, I clicked "continue" which swallowed the exception, and it didn't work until I re-connected to the USB Gecko, then the app continued to run just fine.
Thanks for the input.. well, the exception would be passed on if I used try-finally.. I admittedly used try-catch which would normally catch an exception and handles it.. unfortunately the structure itself can hardly be changed to try-finally because of the return command in the main code. As of such I went this way.. for a messagebox: admittedly, no messagebox should be opened in usbgecko.cs as it does not belong there imo. I will handle exceptions in the main code though! Right now I am outlining a global exception handler which would give proper message boxes in case errors appear and handle the code accordingly.. it is admittedly a bit difficult as some functions like breakpoints run threaded and accessing main form elements from threads can be quite tricky.. I will be working on a solution for proper exception handling though!
Quote from: Link on March 06, 2010, 08:18:42 PM
Unfortunately the structure itself can hardly be changed to try-finally because of the return command in the main code.\
I think I understand what you're saying. I am pretty sure you can put a return in the try block of a try-finally statement and the finally is _always_ executed before you return. The only thing that could possibly stop a finally block from executing is an exception in the finally block.
http://www.discussweb.com/c-programming/2448-if-i-return-out-try-finally-c-does-code-finally-clause-run.html (http://www.discussweb.com/c-programming/2448-if-i-return-out-try-finally-c-does-code-finally-clause-run.html)
Quote from: dcx2 on March 06, 2010, 08:26:23 PM
Quote from: Link on March 06, 2010, 08:18:42 PM
Unfortunately the structure itself can hardly be changed to try-finally because of the return command in the main code.\
I think I understand what you're saying. I am pretty sure you can put a return in the try block of a try-finally statement and the finally is _always_ executed before you return. The only thing that could possibly stop a finally block from executing is an exception in the finally block.
http://www.discussweb.com/c-programming/2448-if-i-return-out-try-finally-c-does-code-finally-clause-run.html (http://www.discussweb.com/c-programming/2448-if-i-return-out-try-finally-c-does-code-finally-clause-run.html)
I checked MSDN too.. seems like try-finally works.. well, as I often mentioned this is my first big C# project, thanks university which only taught Java (which I personally dislike because of its horrible speed) and Delphi (which while being fast has the issue of expensive compilers and everything). But yeah, I'll change the block then!
Version 0.42 now:
changes since 0.40 are (so 0.41 changes also included):
-refining should be fixed (spotted the error)
-readme now included
-breakpoint fixes
-dec to hex buttons removed, context menu instead which also provides float to hex and such
-search within memory view added
-under-the-hood-changes
-notepad changed to a tab view
-GCT code list scrolls vertically now
-arrow navigation possible on GCT tab
-changed up/down buttons in disassembler tab (they were wrong way around!)
-auto-update in memory viewer fixed
-context menu in disassembler tab added (Breakpoint, Poke and GCT code)
-that nasty bug with VC/WiiWare games should be gone for good
-exception handling (the app shouldn't crash during a transfer error but show error messages)
-checks whether external exe files are there rather than just crashing if it tries to execute them and they are not there
Sources and binaries have been updated
Binaries: http://l0nk.org/gdnb.zip
Source code: http://l0nk.org/gdns.zip
From WiiRD differences:
QuoteDisassembler:
No difference to WiiRd actually.. just replacing commands should instantly work this time not after 100 tries (strange bug in WiiRd GUI noone really understands!)
I found that if you pause, then hit update, then hit run, it would work every time. The only time it wouldn't change is if the game not paused. This was in contrast to poke, which would work while the game was not paused.
Awesome job link ;)
Thanks Link.
For all VS users out there I have started using a plug-in called ReSharper (http://www.jetbrains.com/resharper/index.html)
It's VERY useful
P.S. getting the following with the source:
Could not find type 'GeckoApp.BPList'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built.
Quote from: Panda On Smack on March 08, 2010, 10:33:40 AM
Thanks Link.
For all VS users out there I have started using a plug-in called ReSharper (http://www.jetbrains.com/resharper/index.html)
It's VERY useful
P.S. getting the following with the source:
Could not find type 'GeckoApp.BPList'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built.
I wonder about all those compilation errors.. I basically cleaned my netbook reinstalled Visual C# 2008 Express on it and moved over the code and it instantly compiled! If you like help please feel free to contact me directly (IMs or so)
I needed to do a Build before opening the MainForm, or the Designer will give that error. BPList (and NotePage) are custom controls that should appear in your Toolbox. If you don't see "Gecko dNet Components" in your toolbox (probably at the top) then you need to build the solution once and look for a "Build Succeeded" message at the very bottom. Then, your Toolbox should be updated and Designer will stop complaining.
Perhaps if these controls were in a separate project, we could set up a project dependency, but this should only be a problem the very first time it's ever opened on a machine.
FYI, I am also using Visual C# 2008 Express at home. And let me ++ the suggestion for things like ReSharper, we use something like it where I work and some of the stuff it can do is absolutely amazing...
Quote from: Link on January 03, 2010, 01:33:37 PM
Quote
changes since 0.40 are (so 0.41 changes also included):
-refining should be fixed (spotted the error)
-readme now included
-breakpoint fixes
-dec to hex buttons removed, context menu instead which also provides float to hex and such
-search within memory view added
-under-the-hood-changes
-notepad changed to a tab view
-GCT code list scrolls vertically now
-arrow navigation possible on GCT tab
-changed up/down buttons in disassembler tab (they were wrong way around!)
-auto-update in memory viewer fixed
-context menu in disassembler tab added (Breakpoint, Poke and GCT code)
-that nasty bug with VC/WiiWare games should be gone for good
-exception handling (the app shouldn't crash during a transfer error but show error messages)
-checks whether external exe files are there rather than just crashing if it tries to execute them and they are not there
Well, in the C# USB Gecko handler topic there is already some discussion about.
Gecko dotNET is intended to (maybe) replace WiiRd.. it has not too many improvements actually, it is open source though and it is here and then developed with Cross Platform intentions.. as of now as a major addition it has a WatchList and an included notepad where you can create hacking notes.
Screenshots are at: http://l0nk.org/g.net/
To download it:
Binaries: http://l0nk.org/gdnb.zip
Source code: http://l0nk.org/gdns.zip
Thank you.
I just wish you had included the Pointer Option, but overall GREAT JOB! :)
Hey Link
In things like Snes9x you can take a snapshot of your game and restore it later. I presume this is because the memory is fairly small for 8bit/16bit consoles and you just restore every address. Is it possible to do this in Gecko dotNET? Can we somehow snapshot a section of the memory.
I assume its not the whole range of MEM1, MEM2?
Ta
Unfortunatley it is more than just the memory.. first of all:
-it is the full memory of MEM1 and MEM2 INCLUDING(!!!) ARM memory which Gecko has no access to
-it needs to store exactly which instruction is being executed right now on both ARM and PPC (again it has no access to the ARM)
-it needs to dump the complete video memory
-all hardware registers and video registers need to be stored
Even if we had access to ARM memory.. the download of all RAM would take a good 3 minutes.. and then: please don't forget the upload buffers are 10 times smaller.. so upload will probably take a good 10 to 15 minutes.. and I doubt we could call this "quick load" then.
So in short:
-not possible I think :(
Yeah I see what you mean, how is it so easy in emulators like snes9x? I guess the roms on the Wii have been bloated out?
Excuse my lack of knowledge on the subject
An emulator is pretending to be, for example, a Super Nintendo. Because it is pretending, all of the values are already inside the computer's memory, it doesn't need to transfer that data over USB like we do with Gecko. So it's a lot faster for the emulator.
Another reason is that since you're emulating the processor, you know everything about it and you can change whatever you want. According to Link, we don't know what ARM is doing, and even if we did, we still need the whole PPC, and there are some registers we can't just simply write to (like the floating point registers).
Well, basically just compare the specs:
-the Roms for SNES are most likely like a few KB.. the SNES had less than 128 KB RAM and 64 KB VRAM of complete memory (and no seperate video memory).
So in the end.. the emulator only has to dump a few KB
If you already compare that to Project64 which emulates N64.. Project64 takes quite some time to take a memory snapshort.. although an N64 only had 8 MB of RAM (with expansion kit, without it was only 4 - video memory is shared).
Now these emulators have HI-SPEED access to the memory (as it is in your PC memory) and your harddisks are also fast. The USB Gecko connection is very slow in comparison!
Now let's go Gamecube:
-RAM: 24+16 MB
-16 MB of Video memory if I am not mistaken
Wii:
-RAM: 24+64 MB
-32 MB VRAM if I am not mistaken
So you see: we talk different numbers here!
I've had a quick look at the screenshots for Gecko.net and read the back posts and it seems to be shaping up to be all that WiiRD was and more :D Not had a chance to try it out personally yet but I will in a few days.
I made a request in the GeckOS thread regarding decoding of binary bits in a byte, and since it seems that all needed work for this would be on the PC side, I thought I'd post the request here...hope that's ok.
Basically it is the ability to view a 8\16\32 bit value in binary form. This is just for games that use binary bits for a "true or false" purpose for things like items collected and the such. Also, the ability to modify the binary form and having the app turn it back into hex and write it back would be good :)
I'm not sure how easy (or possible) it would be to make GeckOS modify a solitary bit(s) using code-types but I think that having this function in Gecko.net would make finding the bit(s) sooooo much easier :p
Hope you don't mind the request again lol
Quote from: Dude on March 13, 2010, 01:31:17 PM
Basically it is the ability to view a 8\16\32 bit value in binary form. This is just for games that use binary bits for a "true or false" purpose for things like items collected and the such. Also, the ability to modify the binary form and having the app turn it back into hex and write it back would be good :)
Expanding a hexadecimal number into binary would be hard. The text boxes aren't big enough. Compare the relative size of the equivalent binary and hex numbers.
AAAAAAAA
10101010101010101010101010101010
QuoteI'm not sure how easy (or possible) it would be to make GeckOS modify a solitary bit(s) using code-types but I think that having this function in Gecko.net would make finding the bit(s) sooooo much easier :p
I added this as an Operation combo box beside the Poke button on the Memory Viewer tab. You won't see it until Link releases a new build though.
PS: I've been using this thread (http://wiird.l0nk.org/forum/index.php/topic,4954.msg45186.html#new) to track Gecko dotNET feature requests so I suggest posting there instead.
Damn, sorry about that - I had multiples tabs open and clicked the link you posted in the other thread for bugs and feature requests. I guess I closed the wrong thread :$ Sorry again.
Should I post (again :( I feel like a nub lol) in this forum? I think any more posts would be seen as harrasment lol
I did think that there would be a space limitation. But it's just an issue with displaying? Perhaps using a box with a bottom scroller and adjustable columns for codes would work?
I don't want you guys stressing or using up time that would otherwise be used for more important updates and additions, so this can be placed low on the list if it's considered worthy for inclusion :p
Link, I have found that the new search refining system is working fine but 1 problem I'm having is as the search jumps from 1 block to the next the game briefly continues to run in the background.
I noticed this initially with PES. I searched for a value mid game and as I refined the search the game skipped along slightly in the background. I just wanted to flag this up as I presume values will be changing if the game is in play and what may have matched your search criteria initially could be omitted by the time it finishes?
ta
I can corroborate Panda's discovery. I also noticed that the game runs a few frames inbetween the different blocks of the Block Search. Therefore I almost always pause the game when doing searches.
Would it be as simple as pause and resume calls wrapped around the search algorithm? Unless Link has a better idea, I'll try to implement that tonight.
Oh, by the way, be careful with the second search if your first search was unknown. There are two bugs in that code path (I fixed both, but you gotta wait for the new build). In the mean time, if your first search is unknown, do a search equals while the game is still paused so you can "skip" the second search (neither bug affects the equals search). Subsequent searches after the second search are safe. Also, I'm pretty sure all non-unknown searches are safe.
Quote from: dcx2 on March 15, 2010, 05:14:55 PM
I can corroborate Panda's discovery. I also noticed that the game runs a few frames inbetween the different blocks of the Block Search. Therefore I almost always pause the game when doing searches.
Would it be as simple as pause and resume calls wrapped around the search algorithm? Unless Link has a better idea, I'll try to implement that tonight.
Oh, by the way, be careful with the second search if your first search was unknown. There are two bugs in that code path (I fixed both, but you gotta wait for the new build). In the mean time, if your first search is unknown, do a search equals while the game is still paused so you can "skip" the second search (neither bug affects the equals search). Subsequent searches after the second search are safe. Also, I'm pretty sure all non-unknown searches are safe.
OH wait.. pause, resume.. I forgot about that *lol*
Quote
changes since 0.42 are (why 0.51 - because 0.42 accidently read 0.5 in the About tab) - all changes this time by dcx2:
-cancelling searches
-no more complete form deactivation during breakpoints
-Pause bug fixed for searches
-Searches can be stored and loaded
-Double clicking a pointer value in Memory Viewer will jump to the given address
-removing search results
-many under-the-hood bug fixes
-and some more
@dcx2: point to even more things if they are important to you..
Source and binary links have both been updated!
Additional points of interest
-Re-sizable at last!
-Can sort search results by column
-Increased Memory Viewer auto-update performance to match WiiRDGUI
-Right-click in Memory Viewer now selects the cell before popping up the context menu
-Operation (write/AND/OR/XOR/add/sub) for Poke on Memory Viewer tab
-Poke during auto-update
-Up/down/pageup/pagedown working Memory Viewer and Disassembly
-Double click a branch in disassembly to jump there
-Always on Top checkbox (About page, will probably move in the future)
-Custom FPS adjustment to slow the game down (About page, will probably move in the future)
-Remembers some Memory Viewer/Breakpoint/Disassembly fields in case of shut-down or crash
-Auto-Preview with screenshots
There may be more, I have to check the svn log when I get home, but I think that's it
dcx2 noticed some major bugs in the watch list (possible stack overflow).. so I quick updated the binary pack.. the sources have not been updated though ( I lack the time personally but the binaries should be fixed)
FYI: 0.52 also has other small fixes, but the watch list stack overflow was a biggie...it would hit even if you weren't using the watch list. :eek:
-Search results decreasing by 1 fixed
-Deleted search results bug fixed
-Dec -> Hex bug fixed (use right-click context menu)
-Various controls were becoming enabled when they shouldn't be fixed
-Search-Pause bug fixed, again...
-Added "MUL" and "DIV" to Poke Operations box on the Memory Viewer tab
I'm really liking the way Gecko.net is coming along.
Thanks for update! :D The search results decreasing by 1 on every search was an irritant and made me go back to using WiiRD since there was a good chance that I'd miss an important address.
Looking forward to trying out the update later. As always, I'll be keeping my eyes peeled for bugs, etc.
Thanks for the effort you guys are putting into this software! ;D Keep it up.
I think there is some bug with 0.52
I modified a line from the disassembly tab, something like "add r0,r0,r5" to "li r0,500"
or change it by GCT codes
the game would sometimes crash at the same point
however the crash doesn't occur when I use the old wiird
I am not sure how to provide you the details to pin point the bug
please tell me and I will post them here
That is really odd, because I've used the disassembly tab a lot and I've never seen it freeze a game.
Let me see if I understand. You went to the Disassembly tab, and found an instruction "add r0,r0,r5". You changed it to "li r0,500", and hit apply. Sometimes, but not always, the game freezes.
Does it freeze immediately? After a specific amount of time? After a random amount of time? After doing a certain event in the game? Have you tried pausing the game before applying the new instruction? (it should be pausing it for you behind-the-scenes, but I'm trying to cover all the options)
You have also tried this using GCT codes. Are there any other codes, in particular any C2 codes? WiiRDGUI and Gecko dotNET 0.52 both have issues with applying codes after applying a C2 code (the first time always works though). If you don't apply any C2 codes then you won't experience this issue. I think I have a fix for that in the next release of Gecko dotNET, though. However, you said WiiRDGUI doesn't have any problems. So I'm not sure this is it.
What game are you using? After the game freezes, have you tried reconnecting with Gecko dotNET?
You could also try using Poke to overwrite the instruction with the machine code for li r0,500. If the bug is specific to the disassembly tab, this would work fine.
I was playing SMUJAF - Daikaijuu Battle: Ultra Coliseum DX - Ultra Senshi Daishuuketsu
it freezes at the same point just before showing the characters of the match (sometimes, not always)
I haven't try pausing the game.
It freezes even if I only have the line of changing "add r0,r0,r5" to "li r0,500" by GCT
there is no C2 code
I haven't try pausing the game or by poking, will try now
edit: it's weird, I couldn't reproduce the crash today. I will try again later.
To assist with beta testing without requiring Link to distribute a new binary every day, I've decided to start releasing Test Builds. You should still view Link's release as more official than mine, but you can help me get the bugs out for official builds by testing new features (like the float compares or the version digit).
This folder (http://www.mediafire.com/?sharekey=a07f44eebb23c44a111096d429abd3606b702edc8887e28e77b784fef9ed9be3) will hold any nightly builds that I make.
Test build 0.52 r38 includes:
-Show Mem button on the Breakpoint tab. If the current instruction is a Load or Store, click this button to open Memory Viewer at the address that would be Loaded or Stored.
-Conditional branch detection. If the current instruction is a conditional branch, the Show Mem button's text will change to Not Taken or Taken.
-Conditional branch toggling. Click the Taken or Not Taken button to toggle the Condition Register so that the branch switches to Not Taken or Taken.
-When creating a new GCT code from the search/memviewer/disassembly, it now prompts you for a name
-Exact breakpoints work now
-Game is paused while applying codes. This prevents C2 codes from freezing the game when applied more than once
-Deleting multiple search results works correctly, even if they are non-contiguous
-Added Numeric up-down for changing current search result page
-Removed unused dec->hex button
-Added float search result compares
-Added version digit to Form's title bar
-Added byte-resolution to the mouse cursor in the Memory Viewer
The disassembler tab scroll bar has been acting weirdly (forgot since which build)
when pressing the arrows on the scroll bar
it scrolls 2 lines (which I expect to be 1 line)
and sometimes it just keeps scolling and I couldn't stop it
have to wait until it stops
I don't know how you get these weird bugs, Jackal, because the disassembly scroll bar goes 1 line at a time for me when I use the scroll bar. I tested both Link's release and my test release.
Do the up/down arrow keys work as expected or do they do 2 at a time too?
By the way, can we move the discussion of bugs to this bug/request support thread (http://wiird.l0nk.org/forum/index.php/topic,4954.msg45635.html#new)?
Cross posting fail. Test build r41 is up. (http://wiird.l0nk.org/forum/index.php/topic,4954.msg45684.html#msg45684)
How about adding in column width adjustment when you stretch your window to be bigger?
(http://img34.imageshack.us/img34/2334/geck.gif)
The columns will automatically resize themselves according to the contents. I preferred this, so that way when you switch from, say, Dec to Single, you don't have to resize the columns at all. I'll look into whether auto-resize can work with user-resizing.
ta mate
will you release the source for your nightly builds occasionally?
ta
Sure, if there's an interest. It's just a lot quicker to zip up only the exe. To get the sources ready, I have to go through and remove all the intermediate files that are built by the compiler. And most of the time for a nightly build there's only a few dozen lines that are changed out of several thousand lines of code, so the vast majority of it will look identical to 0.51 source. That's why I say this is 99% Link and 1% me.
I'll put the source up with tonight's test build because you asked nicely. ;D Tonight's goals include fixing the version digit and investigating the user-resizeable columns. There's a Property for DataGridView that controls whether the user is allowed to resize columns, but I'm curious as to how that works with the auto-size-to-cell-contents property of each column.
Top man, thanks. Keen to have a play here in VS and help if I can :)
noticed it was the bugs post :P
the version number for wiiware and VC games is offset 6 if im looking at this right ..
HCFE=Wii Speak Channel 2.0(NTSC)
_________
45464348
0002FFFF
_________
the 0002 is the version numbers ..
o and dont know if this will help u guys but iv finished the NTSC Gamelist for wiird .. might be able to convert it to this apps Format
http://www.codemasters-project.net/guides/showentry.php?e=279
download the gameslist
only game that is Redsteel 2 Do hope this helps Note is has some Pal but not all of them ..
Quote from: Skiller on March 26, 2010, 03:47:10 AM
Quote from: dcx2 on March 26, 2010, 02:45:07 AM
Gecko dotNET 0.52 Test Build r41 (http://www.mediafire.com/?nzgmgzg1xzi)
release notes
-Added "View Mode" to search results. Options are hex, decimal, and single.
-Added "Change" column to search results. new value - old value
-Added "Step out" to breakpoint tab. Repeatedly calls Step Over until it reaches blr
-Search-Pause-Resume finally works the way it should. Honest. >.> <.< No, really, I mean it this time. ... *crosses fingers*
Skiller - Actually, that would be offset 5, because we start counting from 0. I'm wondering (hoping!) that the 00 before the 02 is actually a null byte terminating the previous string. If you could provide me with the first couple eight bytes of a few WiiWare/VC games, and any Wii games (EDIT: that aren't version 1 games), I'll see what I can do. I want to compare how the different games store version numbers.
EDIT:
Doh, meant to post this in the release thread, not bug requests...
Just like IOS the games can have upto version FFFF :P its a STH
Most of my games are all version 1 .. :P
Guitar Hero 3 V2
5247484535320001
Alone in the Dark
52524B4537300001
Birthday Party
5232594535340001
Cosmic Family
5243464534310001
Mario Party 8 (i know there is more then just 2 versions of this one .
524D384530310001
WiiSports
5253504530310001
The Legend of Zelda Twilight Princess (Ver 3)
525A444530310002
Game Party
5247584535440000 <-- Version 1
5247584535440001 <-- Version 2
Gecko dotNET 0.52 Test Build r43 (http://www.mediafire.com/?sharekey=a07f44eebb23c44a111096d429abd360a09f0140dc2c9234bf1b77d2eb488dac) (source included)
-Attempted Version digit title text again. Should work for Wii games and VC games.
-Search results are user-resizeable now (trickier than I thought...if you see any odd behavior let me know)
-Right-clicking an un-selected search result will select that result (and unselect any others!)
-Support for copying selected search results to the clipboard
thanks!
It's been quiet for a few days, so I hope r43 has been working out well for everyone. ^_^ I'm probably going to promote r43 to an official build in the future.
In the mean time, I've been working on a Code Wizard for the past three days. It's in the new r45 build (http://www.mediafire.com/?sharekey=a07f44eebb23c44a111096d429abd36050e9679a3117e894b99f3f1679ee9294). It is the only change.
Now, the Code Wizard is not even beta. I've been trying to test it a lot to make sure it can't hurt you (three days!!!), but I really do suggest backing up any codes before using it, just in case.
To use the code wizard, right-click on a search result, a memory viewer cell, or on the code list, and select "GCT Wizard...". You'll see the dialog box pop up, ready to ask you what kind of code you want to do, 32/16/8 bit, ba/po, and so on. The address and data fields are already populated based on what you right-clicked. It checks the addresses for correct alignment, as well. It works with any MEM1 or MEM2 address. You can modify existing codes or create a new code by typing the name into the code name combo box and hitting Enter.
Press "Add Code" to turn the various settings into a code. Press "Store Code" to write the code back to the main form. If you don't press Store Code, then nothing should ever happen to the codes on the main form, so you could just play with the Code Wizard and never hit Store Code if you're worried about data loss.
Currently, the only code types supported are RAM write codes and if codes. If there's more interest in this, I can continue adding codes to the code wizard, and probably create its own thread in this forum for suggestions/bugs/etc.
Wow, did you make a comment about building the code wizard before? Cause I've been thinking on how something like that could be done just a day or two ago along with adding in a pointer search lol if you made a mention of it before then that would explain why I was thinking it XD
It almost feels like this app is gonna be capable of hacking the game FOR YOU. Turn it on, connect and say GO! XP
Shame that there isn't a pointer search though. I have to use WiiRD and it only works if it's connected to the gecko.
Loving the updates though, dcx2. Downloaded the release to try out the code wizard.
Quote from: Dude on March 30, 2010, 09:19:44 AM
Wow, did you make a comment about building the code wizard before? Cause I've been thinking on how something like that could be done just a day or two ago along with adding in a pointer search lol if you made a mention of it before then that would explain why I was thinking it XD
It almost feels like this app is gonna be capable of hacking the game FOR YOU. Turn it on, connect and say GO! XP
Shame that there isn't a pointer search though. I have to use WiiRD and it only works if it's connected to the gecko.
Loving the updates though, dcx2. Downloaded the release to try out the code wizard.
If it makes you happy.. I for myself, am currently brain-storming a concept for a seperate pointer search module.. however, as so many people seemed to complain about pointer search being not in it, I am trying to develop it as a module application.. meaning: yes it would work well as its own user control in Gecko dotNET however, it would also happily run independently. Most importantly it will be able to handle memory dumps which contain BOTH MEM1 AND MEM2 at the same time so pointers from MEM1 to MEM2 will be handled!
huzzah!
What happened to the convert decimal to hex option on the lower value info input box?
That dec -> hex button wasn't for the lower value info box, it was actually for the Different By searches. It became obsolete once I put the Input Convert context menu everywhere.
If you ever want to convert anything between hex and dec or float, right-click the text box you want to change. Almost all boxes that might take a value have the Input Convert context menu on them. Poke values, Breakpoint condition values, etc.
Do you just right click the text boxes or do you have to highlight the text first like WiiRd?
You don't need to highlight anything. And if you did, you could always ask me to fix that. ;D
Not all of the text boxes have the input converter on them. Specifically, text boxes that take addresses, because we never, ever work with decimal addresses.
Ahh, right click
thanks guys
wow. this thing is coming along nicely. i just updated from the first or second version that link put out and im impressed. i have a couple questions...
1) is there any way to have the disassembler run in "live" mode or "sync with the game" mode? the only way i see to adjust the position is to type in a memory address and jump there. It would be nice to just press a button and go to the address that the game is at (if that is even possible).
2) what needs to be done t run this in linux? i remember link saying something along the lines of commenting out the icons for the FST stuff and installing a FTDi package. Also, I saw that the disassembler compiles ok for linux. I already have MonoDevelop, and I can apt-get a FTDi package like there's no tomorrow. Unfortunately, my c# leaves something to be desired, so im just stabbing in the dark as far as commenting the right parts of the fst tab.
Quote from: giantpune on April 01, 2010, 07:12:27 AM
1) is there any way to have the disassembler run in "live" mode or "sync with the game" mode? the only way i see to adjust the position is to type in a memory address and jump there. It would be nice to just press a button and go to the address that the game is at (if that is even possible).
When a Breakpoint is hit, or Step is pressed, the Disassembler should automatically jump to the current instruction. Without setting a breakpoint, there's no way to know what the current instruction is. Now, if you go roaming around the disassembly after hitting a breakpoint, I can see how you would lose your place, and Step would bring you back (which is what I usually do), but if you didn't want to step over the instruction...
There's a lot of space on the breakpoint tab, so I'll consider throwing a "jump to current" in there for ya. ^_^
Quote2) what needs to be done t run this in linux? i remember link saying something along the lines of commenting out the icons for the FST stuff and installing a FTDi package. Also, I saw that the disassembler compiles ok for linux. I already have MonoDevelop, and I can apt-get a FTDi package like there's no tomorrow. Unfortunately, my c# leaves something to be desired, so im just stabbing in the dark as far as commenting the right parts of the fst tab.
Hawkeye commented about the mono version the other day. I have Ubuntu (9.10..? or 9.04) on one of my PCs, so I'll see what I can do. I'll also try to modify the FST stuff so that it checks for a mono preprocessor directive.
I'm not sure the repositories have the appropriately updated version of libFTDI...when I first started hacks, I tried to get the linux version of WiiRD before I realized it was console only. While trying to get that WiiRD to run, I'm pretty sure I discovered the repositories have an old libFTDI.
I will try to use this weekend to figure out how to get the mono build to run. ^_^
is this the correct place for bug reports?
ive found a unhandled exception...
1) start a game with geckoOS and start messing with geckoDotNET
2) have the "disassembler" tab showing and exit the game
3) click the screenshot tab
4) get a popup that the connection with USB gecko is lost
5) leave that popup on the screen and start geckoOS and then start the game again
6) select "ok" to let geckoDotNET reconnect to the USB Gecko
7) get this exception...
[spoiler]
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.ArgumentOutOfRangeException: InvalidArgument=Value of '0' is not valid for 'SelectedIndex'.
Parameter name: SelectedIndex
at System.Windows.Forms.ListBox.set_SelectedIndex(Int32 value)
at GeckoApp.Disassembly.DissToBox(UInt32 address)
at GeckoApp.MainForm.DisPage_Enter(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnEnter(EventArgs e)
at System.Windows.Forms.TabPage.OnEnter(EventArgs e)
at System.Windows.Forms.ContainerControl.UpdateFocusedControl()
************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Gecko dNet
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Documents%20and%20Settings/Administrator/Desktop/vmware_wiishit/geckoDotNET/Gecko%20dNet.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
[/spoiler]
8 ) selecting to continue at the exception lets the screenshot tab open up
9) click the disassembler tab
10) another similar exception
11) clicking to continue through the second exception lets everything run as it normally does
I like you already. The instructions you provide for reproducing the unhandled exception are exquisite. You'd make a good QA tester...is that your day job? ;)
FYI, bugs/requests go here. http://wiird.l0nk.org/forum/index.php/topic,4954.75.html#new (http://wiird.l0nk.org/forum/index.php/topic,4954.75.html#new)
I'll look into this. Thanks for the Exception message, too...that stack trace makes my life 100x easier.
ok, well i have everything here needed to compile and test that booger whenever you get a mono version. I've got monodevelop set up in OSx 10.6.3 and ubuntu 9.10. And I've compiled the vdappc external disassembler for both OSes as well. I really don't care if it works in OSx but I guess I can still test it. So we are ready and waiting on you, sirs :) .
Changes since 0.52; see this post and the three after it http://wiird.l0nk.org/forum/index.php/topic,4886.msg45389.html#msg45389
Search tab:
-View Mode: hex, dec, or Single (aka float).
-Difference column
-Resizable search result columns
-Added Single search result compares in addition to 32/16/8
-Delete multiple non-continuous search results
-Copy search results to clipboard
-Numeric up-down to make it easier to change the current search page
-Removed unused dec to hex button. All value-type text boxes have a much more powerful right-click context menu.
-Finally fixed the search-pause-resume bug?
-Right click selects a search result
Memory Viewer tab:
-When right-click -> set breakpoint, it now detects what byte is under the mouse cursor
Breakpoint tab:
-Step Out; repeatedly calls Step Over until it hits a blr. Can be canceled.
-Show Mem button; If the current instruction is a Load or Store, click this button to open Memory Viewer at the address that would be Loaded or Stored.
-Conditional branch detection. If the current instruction is a conditional branch, the Show Mem button's text will change to Not Taken or Taken.
-Conditional branch toggling. Click the Taken or Not Taken button to toggle the Condition Register so that the branch switches to Not Taken or Taken. Be careful because toggling could freeze the game if the code doesn't have the right data loaded
-Fixed exact breakpoint bug
GCT code tab:
-right click context menus that create new codes will prompt for user names
-Game is paused while applying codes. This stops some games from freezing if you repeatedly apply C2 codes.
General:
-Added version digit support to title bar; if the game version is not 1, it should say so
-To make it easier to modify existing codes, there is a new code wizard. This is feature is alpha but designed in hopes of making it easier to . Right-click on a search result or memory viewer cell and select code wizard. It will populate the wizard with a temporary copy of all your codes and the address and value you selected, and ask for things like ba/po, 32/16/8 bit, etc. It can do RAM writes, fills, end-ifs, and masks. It checks alignment and handles changing the ba/po for all of MEM1 and MEM2 with a terminator. The magic happens when you press Add Code. To make the magic permanent, click either of the red buttons. They are red to stress the alpha nature of this feature...it shouldn't hurt you but I would probably back up my codes before pressing the red buttons. The black buttons are always safe and never do anything to the codes
I'm trying to get Gecko.NET to build in MonoDevelop. I commented out the lines in FST that called IconReader. In USBGecko.cs, I switched the preprocessor directive to build the Mono build. I got libftdi from the repository and copied libftdi.so to the local directory. Unfortunately, the repository contains 0.16-2, but the latest sources are 0.17-1. I'm not sure if the repository's version is too old...
However, when I go to run, it tries to connect but then it gets upset when it tries to marshal the byte[] readBuffer that's inside the ftdi_context struct. I guess the MonoDevelop I installed doesn't support debugging, because it won't hit the breakpoints I set. I tried changing the byte[] to an IntPtr and it gets a little farther, but still dies.
Quote from: Link on March 31, 2010, 08:24:53 AM
Quote from: Dude on March 30, 2010, 09:19:44 AM
Wow, did you make a comment about building the code wizard before? Cause I've been thinking on how something like that could be done just a day or two ago along with adding in a pointer search lol if you made a mention of it before then that would explain why I was thinking it XD
It almost feels like this app is gonna be capable of hacking the game FOR YOU. Turn it on, connect and say GO! XP
Shame that there isn't a pointer search though. I have to use WiiRD and it only works if it's connected to the gecko.
Loving the updates though, dcx2. Downloaded the release to try out the code wizard.
If it makes you happy.. I for myself, am currently brain-storming a concept for a seperate pointer search module.. however, as so many people seemed to complain about pointer search being not in it, I am trying to develop it as a module application.. meaning: yes it would work well as its own user control in Gecko dotNET however, it would also happily run independently. Most importantly it will be able to handle memory dumps which contain BOTH MEM1 AND MEM2 at the same time so pointers from MEM1 to MEM2 will be handled!
I would love to have a pointer search module that could run independently. That would save having to have Gecko.net or WiiRD connected and running in order to utilise it :D
Thank you for considering this, Link :)
The new Gecko dotNET has been awesome so far, great work!
However, today I came upon a bug, it seems.
It started when I tried to use this code:
infinite cycling stamina [wiiztec]
20DEEFEC 00000003
04DEEFC0 7F800000
E0000000 80008000
In Wii Sports Resort USA.
First time, tried applying at the menu, game froze, but code worked when applied in the actual cycling game; I assumed it was poor testing. So, I've been spending the last 6 hours or so trying to make it not freeze at the menu, getting extremely confused when nothing worked that looked to be very obviously correct. Even the original code itself looks to be just right, other than the unneeded last line.
Finally I decided it could be a bug in GDotN, and started the original WiiRD, and the original code (and the other 3 versions I came up with) work, without freezing. Now I'm extremely confused- this seems to have been a problem in the code handling, which Gecko OS does- not GDN. Is it a problem with if CTs? But I also made an ASM version without If's, and it works fine, but freezes whenever I try to load the menu when applied through GDN.
Did I miss a file or something? Could someone else test that code in dotNET? I'm very confused here :P
FST reads no longer work :S
i have only tried on OSSleepThread and AXNextFrame, but they worked before on CoD:MWR and now they're not. I assume it is because of GeckoDotNET
Do other codes cause a similar problem, or is it just codes like that one? I don't have Wii Sports Resort, so I can't test it. But Gecko.NET pauses the game before applying codes and unpauses the game afterward. This is because applying C2 codes multiple times can freeze some games; this happens with WiiRDGUI too.
By "pause", I mean "set an execute breakpoint at the entrance of the code handler". This way the processor doesn't stop execution while the game is doing something. It's possible that the game did not "unpause" after the codes were applied (I had a similar problem with pausing during code searches). Always at least try clicking the run button and/or reconnect, because the only times I have seen a true "freeze" is when it's trying to dereference a bad pointer with load or store.
Also, that last line is in fact necessary. It not only resets ba/po (which is unnecessary), but it also does end-if (which *is* necessary).
EDIT:
missed hetoan's comment. I've never played with the FST stuff, I'm not even really sure how it works. Link will have to chime in on that one.
Quote from: REDSOXROX on April 04, 2010, 06:54:42 AM
The new Gecko dotNET has been awesome so far, great work!
However, today I came upon a bug, it seems.
It started when I tried to use this code:
infinite cycling stamina [wiiztec]
20DEEFEC 00000003
04DEEFC0 7F800000
E0000000 80008000
In Wii Sports Resort USA.
First time, tried applying at the menu, game froze, but code worked when applied in the actual cycling game; I assumed it was poor testing. So, I've been spending the last 6 hours or so trying to make it not freeze at the menu, getting extremely confused when nothing worked that looked to be very obviously correct. Even the original code itself looks to be just right, other than the unneeded last line.
Finally I decided it could be a bug in GDotN, and started the original WiiRD, and the original code (and the other 3 versions I came up with) work, without freezing. Now I'm extremely confused- this seems to have been a problem in the code handling, which Gecko OS does- not GDN. Is it a problem with if CTs? But I also made an ASM version without If's, and it works fine, but freezes whenever I try to load the menu when applied through GDN.
Did I miss a file or something? Could someone else test that code in dotNET? I'm very confused here :P
The last line is not unneeded any conditional (if) code needs an end if at the end the E0000000 80008000 serves this purpose
Ooh right my bad, forgot about needing endif :D
I'll try the reconnect button- I always tried pressing run, never realized reconnect might help as well.
Wiiztec, does your code work for you in dotNET?
I tried pressing reconnect, disconnecting, reconnecting and running several times, still stays frozen. Although it does indeed not seem like a complete freeze; I can still access memory, disassembler, FST, etc, and the music still advances when I press run (as in, the beeping pitch changes)
It seems almost like it is stuck in pause where run goes to the next frame, but the video does not change at all like it would if next frame was pressed.
When I get an opportunity, I'll provide a checkbox to disable the pause-while-applying-codes. I hope that might solve your problem, but I'm not sure why you're having the issue in the first place.
What if you remove the 04 write and just leave the 20 if and the E0 terminator? Does it still cause problems?
20DEEFEC 00000003
E0000000 80008000
Quote from: dcx2 on April 02, 2010, 05:39:49 AMIn USBGecko.cs, I switched the preprocessor directive to build the Mono build.
How did you do that exactly? My knowledge of C# is quite lacking, so I'm not exactly sure if I'm applying the right changes.
Quote from: dcx2 on April 02, 2010, 05:39:49 AMHowever, when I go to run, it tries to connect but then it gets upset when it tries to marshal the byte[] readBuffer that's inside the ftdi_context struct. I guess the MonoDevelop I installed doesn't support debugging, because it won't hit the breakpoints I set. I tried changing the byte[] to an IntPtr and it gets a little farther, but still dies.
Did you install MonoDevelop through the repos? If so, which packages did you install?
I'm gunna make a separate thread regarding the quest to make Gecko.NET work in mono. In the mean time...
Quote from: hawkeye2777 on April 05, 2010, 10:30:46 PM
Quote from: dcx2 on April 02, 2010, 05:39:49 AMIn USBGecko.cs, I switched the preprocessor directive to build the Mono build.
How did you do that exactly? My knowledge of C# is quite lacking, so I'm not exactly sure if I'm applying the right changes.
At the top of USBGecko.cs, add the line "#define MONO". I'm probably going to add some code to FST.cs that also checks for MONO and comments out the IconReader stuff.
QuoteDid you install MonoDevelop through the repos? If so, which packages did you install?
I'm looking in the Synaptic Package Manager right now. I've got Monodevelop 2.0+dfsg-2ubuntu3. Now that I'm taking a closer look, I also see two debugger plugins, Mono Debugger and GNU Debugger...I guess one of those might be useful for running Debug builds, huh?
Quote from: dcx2 on April 05, 2010, 11:04:02 PM
I'm gunna make a separate thread regarding the quest to make Gecko.NET work in mono. In the mean time...
Ok, I'll move Mono talk there as soon as you make it.
Quote from: dcx2I'm looking in the Synaptic Package Manager right now. I've got Monodevelop 2.0+dfsg-2ubuntu3. Now that I'm taking a closer look, I also see two debugger plugins, Mono Debugger and GNU Debugger...I guess one of those might be useful for running Debug builds, huh?
If you'd like the latest version of MonoDevelop, try running these:
sudo add-apt-repository ppa:directhex/monoxide
sudo apt-get update
sudo apt-get install monodevelop monodevelop-debugger-mdb monodevelop-debugger-gdbThe first line adds a PPA with the latest version (2.2.1) of MonoDevelop (located here (https://launchpad.net/~directhex/+archive/monoxide)); the second updates your sources, then the last installs those specific packages (along with their dependencies). In case you don't want to mess with PPAs, the following should work as well:
sudo apt-get install monodevelop-debugger-mdb monodevelop-debugger-gdbEDIT: I forgot that the Mono stuff coded into GDN is Linux specific from what I saw, so more OS-specific checks would have to be made for libraries like libftdi.
EDIT (2): I can confirm that breakpoints work on my end with MonoDevelop from the PPA (with those packages installed).
Gecko.NET 0.60 test build r50 (http://www.mediafire.com/?y1zq4dzzzy2)
Memory Viewer addresses are now black instead of white
various Memory Viewer selection bugs, like changing page, changing tabs, changing view mode, pageup/pagedown
various Memory Viewer display bugs; up/down address text box changes by 0x10 instead of 0x100, up/down arrow keys work properly now, shift+up/down arrow keys will move page without changing selected row/column
SplitContainer for breakpoint tab's registers and disassembly, so the user can resize them
Checkbox to pause while sending codes
Checkbox to confirm Breakpoint-style Next instead of less accurate Pause/Wait/Resume-style Next
Remembers the window size between runs, so you don't have to resize it each time. If you think of any other values that you'd like to have remembered between runs, just ask in the request thread.
I was going to try to do more, but Visual Studio Express Edition suddenly refused to start until I registered (WTF? It's free!), which requires making a Windows Live account. Really irritating...
Gecko.NET 0.60 test build r51 (http://www.mediafire.com/?1mo4zotimn3)
up/down beside Memory Viewer Address text box changes by 0x100 again, like pre-r50 builds
Memory Viewer Address text box supports keyboard up/down arrows to change by 0x10, and pageup/pagedown to change by 0x100
test build r52 (http://www.mediafire.com/?izromtyttyi)
Fully functional Memory Viewer scrollbar control that can do 0x10 changes if you click on the arrows, 0x100 changes if you click above/below the scroller, can drag the scroller around, etc.
Search result context menu Memory Viewer shortcut and Show Mem button on breakpoint tab now center the target address in the Memory Viewer so you can see above and below it
In Memory Viewer, the full byte-aligned address that the mouse is hovering over now appears, instead of just the last hex digit
Pressing the Enter key in the Memory Viewer address text box now jumps the memory viewer to that entry
Added "New Code" to the GCT Code Wizard dropdown names so you can create a new, blank code
test build r54 (http://www.mediafire.com/?xmh3tm1wzjj)
Just about everything that changes the selected Memory Viewer address will try to center that address in the viewer grid
Pressing Enter in the Memory Viewer address box selects that address
Fixed Memory Viewer scrollbar range exception
Added Disassembler to Memory Viewer context menu
Added Memory Viewer to Disassembler context menu
Breakpoint's Show Mem now works with stwu
Cheers dcx
What else are you planning?
This is exciting, I have been keeping up with this thread for a while and can't wait to use geckodotnet again.
My primary concern is almost always to handle the issues in the bugs/requests thread. I much prefer making changes that someone wants right now, as opposed to making up new stuff they might have no use for. Does anyone ever use the Show Mem button? How about the GCT Wizard? Sorted search results?
For instance, I would quite often write a cheat code in pieces, and that is the itch the GCT Wizard was initially designed to scratch. Despite how it may look like it's supposed to make it easier to create new codes, it is actually designed to make it easier to add to existing codes. It took me at least a dozen hours, it's still only roughly 20% done, and I don't even know if anyone has tried it out
Ideas like the GCT Wizard take a long time to bring to life. It took almost 3 straight days to make and test. This is another reason why I like bugs/requests, because I can pick the low-hanging fruit and do several in a day, and still have spare time. When there is no demand and the goal is difficult, there is little incentive to do something hard.
Even something basically supported by the .NET framework itself, like properties that turn on sorting and deleting search result elements, eventually revealed subtle bugs that took a few test builds to find. That people see these bugs is also acknowledging that they're using the feature, too.
So, with that out of the way, here's a brainstorm (http://wiird.l0nk.org/forum/index.php/topic,4954.msg46182.html#msg46182) of some ideas I have in the requests forum, and if anyone wants to see any of these features sooner rather than later, please go there to make known their level of usefulness.
Not sure if I should still post Mono stuff here, but anyway...
I was messing around with GDN (Mono), and I got it to load without crashing. It appears that it segfaults when it either cannot find the USB Gecko or when it cannot write to it (not sure which).
Unfortunately, I still haven't been able to get it to connect to the USB Gecko. So dcx2, if you have an idea of how to trace where the connection process fails (e.g. what breakpoints to set), I'll help test if you are unable to get debugging to work on your end.
haha, I totally forgot I wanted to add mono support to the big ass request list. I know there are like three different people who expressed interest in it.
I really do, seriously, plan on attacking the mono thing soon. I want to make a thread with instructions on how it can be built in Mono. I really like the idea of tinkering in MonoDevelop, building my own packages, etc. ;D Linux is just damn fun.
Did you try running as root? I think the ftdi driver might not be very user-mode friendly. :( ...Linux is just damn hard.
Perhaps we could make a Hello World...something short app that just creates a USB Gecko object and attempts to read from it and display the bytes?
Quote from: dcx2 on April 10, 2010, 02:34:05 AM
My primary concern is almost always to handle the issues in the bugs/requests thread. I much prefer making changes that someone wants right now, as opposed to making up new stuff they might have no use for. Does anyone ever use the Show Mem button? How about the GCT Wizard? Sorted search results?s.
show mem button is extremely usefull I used to have to use address calculator to to put the register value that a stw/lwz uses into the address box and look at the last 16 bits of the ASM instruction hex and put that into the offset box press go and then copy the calculated address then go to the mem viewer and press enter. Now all I have to do is press show mem. I've used the GCT wizard a few times I'm mostly used to putting the codes together myself though. What are sorted search results?
Quote from: dcx2 on April 10, 2010, 02:59:01 AM
haha, I totally forgot I wanted to add mono support to the big ass request list. I know there are like three different people who expressed interest in it.
I really do, seriously, plan on attacking the mono thing soon. I want to make a thread with instructions on how it can be built in Mono. I really like the idea of tinkering in MonoDevelop, building my own packages, etc. ;D Linux is just damn fun.
Did you try running as root? I think the ftdi driver might not be very user-mode friendly. :( ...Linux is just damn hard.
Perhaps we could make a Hello World...something short app that just creates a USB Gecko object and attempts to read from it and display the bytes?
I can make packages and maintain them for Ubuntu, but probably not other distros. Yeah, Linux is both fun and hard at the same time, which is one of the many reasons why I use it.
I did try running as root; no luck. I was able to connect to the USB Gecko via WiiRd console though (as normal user after chmoding some stuff).
A small app might help pinpoint the problem better; good idea. I actually don't mind C# that much, I've learned to like it the more I work with it.
Quote from: wiiztec on April 10, 2010, 04:16:13 AMWhat are sorted search results?
You can sort search results by any column, ascending or descending, by clicking on that column's header. It's just like columns in Windows Explorer.
So you could sort by values descending, and start deleting all the results that are clearly too large. Then search again, sort by change descending, and delete all the results that are wrong because they changed by way too much.
...perhaps I should add sorting and deleting to the context menu, so they're more visible?
Quote from: hawkeye2777 on April 10, 2010, 04:57:19 AMI was able to connect to the USB Gecko via WiiRd console though (as normal user after chmoding some stuff).
Well, if WiiRD is working, then it's not a driver issue. I'm sure once I can step through code this will be much easier.
QuoteA small app might help pinpoint the problem better; good idea. I actually don't mind C# that much, I've learned to like it the more I work with it.
The more I use C# the more amazed I am at how powerful and well-documented the .NET framework is. It really is a pleasure to write C# programs, because everything is just so easy.
test build r56 (http://www.mediafire.com/?nyimmwqmihd)
Assuming no one finds any issues with r56 in the next few days, it will probably graduate to 0.61. There's a few stability fixes that I would like to get on the front page before my next goal of refactoring address and value text boxes (this will make some things easier, like combobox histories and 10-digit decimals), which is a bit trickier.
Memory Viewer:
- Pressing enter on a selected cell which contains a valid address will jump there
- ctrl+c or context menu to copy the selected cell's contents to the clipboard
- ctrl+shift+c or context menu to copy all Memory Viewer contents to the clipboard
Search:
- Added Sort and Delete to search result context menu to increase their visibility
Codes:
- Context menu to enable/disable all code lines (like commenting/uncommenting them all out)
Changes since 0.60; see this post http://wiird.l0nk.org/forum/index.php/topic,4886.msg45895.html#msg45895
- Checkbox to confirm Breakpoint-style Next instead of simpler Pause/Wait/Resume-style Next
- Remembers the window size between runs, so you don't have to resize it each time. If you think of any other values that you'd like to have remembered between runs, just ask in the request thread.
- Killed bugs and other things that aren't very interesting to describe
Search:
- Added Sort and Delete to search result context menu
- Context menu Memory Viewer shortcut centers the target address in the Memory Viewer
Memory Viewer:
- various Memory Viewer selection bugs, like changing page, changing tabs, changing view mode, pageup/pagedown
- Memory Viewer address box keyboard controls
-- Enter to select the address
-- Up/Down arrow keys change by 0x10
-- Pageup/Pagedown keys change by 0x100
- Grid
-- ctrl+c or context menu to copy the selected cell's contents to the clipboard
-- ctrl+shift+c or context menu to copy all Memory Viewer contents to the clipboard
-- Added Disassembler to context menu
-- Fully functional Scrollbar with its own separate context menu
-- All 32-bits of the byte-aligned address that the mouse is hovering over now shown, instead of just the last 4 bits
-- Up/Down/Pageup/Pagedown work right
-- Shift+up/down to move page by one line without changing selected row
-- Addresses are now black instead of white
Breakpoint:
- Show Mem now works with stwu
- Show Mem centers the address in Memory Viewer
- Resizable splitter separates breakpoint registers and assembly
Codes:
- Context menu to enable/disable all code lines (like commenting/uncommenting them all out)
- Checkbox to pause while sending codes (can help when applying C2 codes more than once)
- Added "New Code" to the GCT Code Wizard dropdown names so you can create a new, blank code
Disassembler:
- Added Memory Viewer to Disassembler context menu
looking good, becoming quite advanced now
is there a reason vdappc.exe isn't included in the zip? Doesn't matter just wondered
...uh...uhm....yanno, I didn't even realize. Fixed.
cool, just stops you doing breakpoints if it's not there
ta!
test build r62 (http://www.mediafire.com/?mfyqfmvinmz)
All TextBox's that had address are now special AddressTextBox's. What does that mean for you?
- They check the validity of their inputs. If the address is not valid, the background is colored a faint red.
- They prevent you from entering non-hex digits
- They support history. All of the history functions are available from the context menu. In addition...
-- Double-click to show history
-- up/down to scroll through history
-- Ctrl+Enter adds the address to the history
-- Ctrl+Delete removes the address from the history
-- Ctrl+Shift+X to cut all history addresses into the clipboard
-- Ctrl+Shift+C to to copy all history addresses into the clipboard
-- Ctrl+Shift+V to paste all history addresses from the clipboard
-- Ctrl+Shift+Delete to clear the history
-- Enter/Click on a history address in the dropdown to select it
-- Delete on a history address in the dropdwon to remove it
EDIT: oops, forgot to mention.
-- Auto history checkbox in context menu will add any valid address to the history when the textbox loses focus
test build r68 (http://www.mediafire.com/?z22yzejmjlj)
- Fixed conditional branch detection bug (less than and equals were backwards)
- Breakpoint Condition Value register is now updated with the current selected register's value:
-- on a breakpoint
-- on a step
-- when the current selected register dropdown is changed
This was designed primarily to make SRR0 != conditions easier to set (i.e. "don't break on this instruction"). But it should make all conditions easier.
There's probably going to be some re-working on the breakpoint condition list box next; I feel a context menu coming on...however, due to real life, updates are probably going to be slow for a few weeks.
just saying. a couple of things are still broken.
FST reads still don't work when they do in wiiRD :S
along with that is a slightly bigger bug... when trying to upload codes in the 81XXXXXX memrange it will freeze kinda randomly. It's definitely not gecko OS because it works with wiiRD and not with geckoDotNET. :(
you can see this if you upload any codes with the 05, 03, 07, etc. codetypes.
Also i'm not the only one experiencing this. If it matters the game is Call of Duty Modern Warfare Reflex. It could be because it requires the OSSleepThread hook. I dont really know :P
Quote from: hetoan2 on April 22, 2010, 10:21:54 PMFST reads still don't work when they do in wiiRD :S
I don't know anything about the FST tab, and I've never used that feature of WiiRD. If someone else wants to step up and fix the FST tab that'd be awesome.
Quotealong with that is a slightly bigger bug... when trying to upload codes in the 81XXXXXX memrange it will freeze kinda randomly. It's definitely not gecko OS because it works with wiiRD and not with geckoDotNET. :(
Can you give me the exact code you used? Can you give more details beyond "freeze kinda randomly"? When does it freeze? Did you try doing pause while sending codes? Does it freeze when it's the only code that's active?
QuoteAlso i'm not the only one experiencing this. If it matters the game is Call of Duty Modern Warfare Reflex. It could be because it requires the OSSleepThread hook. I dont really know :P
I don't think OSSleepThread would make any big difference, and if OSSleepThread was a big deal then it would screw up with WiiRD too. When you send codes to Gecko OS, it writes them into memory. You can actually use Memory Viewer to go take a look at the codes that are stored in memory, and you can even poke them. That's why it's really weird if a code does one thing with Gecko dotNET and another thing with WiiRD...because they're both writing the same values to the same place (or they should be...I didn't write any of the code that interfaces with the USB Gecko)
the only code i have that could possibly show this is for call of duty modern warfare.
I cant post it here because it works online. Pc me if you're interested. Otherwise i'll just live with using wiiRD to upload my codes :S
test build r70 (http://www.mediafire.com/?jlnzn3e2mvj)
-AddressTextBox AutoHistory enabled by default
-AddressTextBox should change location properly
-AddressTextBox ContextMenu now lists Copy/Paste as well
-MemView Search button centers the selected address
-MemView address updown centers selected address
-MemView address updown supports pageup/pagedown keys
-Search comparison type dropdown lists all options without a scrollbar
-Register Editor Dialog comes up on top if needed, textbox is given focus when shown
-Watch list updates faster. Still slower than Memory Viewer, but should be more tolerable now
-Watch list was causing random exceptions
I couldn't make the history paste give an unhandled exception. Or the register editor dialog unhandled exception. If you could get the exception again, and copy/paste the exception dialog text into a post, I might be able to narrow it down. But it might have been related to the watch list?
test build r71 (http://www.mediafire.com/?2z2tz5fxctn)
-Fixed Breakpoint Conditions
-BPCondition context menu - Copy, SRR0 !=, SRR0 ==, Delete, Clear
-Delete key works in BPCondition list
-Disassembly context menu - Copy
-Loading search sets "last value" correctly
I wanted to once again thank-you for your continuous development with Gecko dotNET :)
yeah, appreciate the fine tuning
test build r72 (http://www.mediafire.com/?o0nmojwlriz)
-AddressTextBox supports multi-poke now
-RegisterDialogBox exception fixed
-Show Mem supports lhz
-Disassemble() properly closes FileStream
-sleep(100) after gecko.Pause() because otherwise it doesn't seem to work
-MessageBox when there are no search results
-a CenteredMemView that doesn't change the selected cell. fixes a few Memory Viewer display-jumping bugs with the scrollbar and arrow keys
-eliminated hex->float rounding
-Enter key in one-line assembler emulates clicking Assemble
test build r73 (http://www.mediafire.com/?aq0z10yntlx)
-Breakpoint Group Conditions - all conditions in a group are ANDed, but all groups are ORed. Only one group needs to be true, but all conditions in that group must be true
-Breakpoint group number is prefixed to the condition in the ListBox
-To change condition group number, select conditions to change, right click, Set Condition Group, enter the new value and press enter
-Rearranged Breakpoint Tab so that Active Conditions is resizable
Nice :)
Those groups should come in handy.
And even while this is not the request thread, I second what Mathew_Wi said.
Poking the old value would be more practical because the current value could still be the value it was while searching, so poking it wouldn't change anything.
test build r74 (http://www.mediafire.com/?zyndaqczymm)
-Rearranged Breakpoint tab some more. Not quite what wiiztec suggested, but close.
-Fixed one-line assembler problem with bctr/bctrl/blr
test build r75 (http://www.mediafire.com/?mzwm2qitiof)
-Poke initialized with old value
-Current BP condition copy would always copy all of them. Renamed it Copy All
-Added Copy selected BP conditions
-Paste BP conditions
-Step until breakpoint conditions
-Active Conditions checkbox to enable them
-Make connecting cancel-able
test build r76 (http://www.mediafire.com/?nmg1fmzmxym)
-Testing a small difference between the way WiiRD generates the Cheat data and the way Gecko.NET treats the Cheat data before sending it to the code handler. I am hoping that this might fix how Gecko.NET seems to break on certain code types. If you had problems where Gecko.NET would freeze the game and WiiRD would not, please try this build with the problematic code.
cheers dcx (what is your name btw?), I had that a few times so will test this out
ta
the tool is good BUT, my Desktop Symbols blink extremly when i activate the Update in Memory Viewer :-\
and plz make the font in memory viewer Higher. The font is very small or a option i can change the font and font size. Or a settings Dialog with Options for Fonts, Font size with Save and Load Settings function. :)
and a view mode with 8Bit, 16Bit and 32Bit. the 8Bit and 16Bit view mode is better for orientation for VC Games.
i found a tool, in Memory viewer, when a Value change, the Cell become a green color.
The Pointer have Red Color in cell's ^^
Hey guys,
I'm having problems with starting either WiiRD or GeckodotNET at the moment.
I don't know what happened but I always could it getting to work.
Its now saying 'Resetting USB Gecko device driver! Connection resetted!' etc..
I tried re installing the drivers but the drivers remain on my PC so when I re plug it it will just work again without even asking for drivers.
Any hints or help on this?
Thanks!
Adr990
(Windows XP SP3)
@adr - You might need to go through Device Manager and uninstall the driver, otherwise it will find the old driver every time you plug it in.
@ozelot - I don't know what Memory Viewer Auto Update would make your desktop blink. What OS are you using?
I can look into adding font control. My first attempt would probably just read the font from a configuration file.
I would like to make the Memory Viewer cells have color, eventually. I don't know if the DataGridView will support individually colored cells. To keep with Visual Studio's debugger, I would make the changed cells colored red.
@panda - It doesn't really mean anything...that's part of why I picked it. :)
ok, also i have xp sp2 :D but, or I test that again
test build r77 (http://www.mediafire.com/?5rd0muytmnw)
-Fixed a devastating bug that could cause loss of codes when reconnecting!
-Fixed a bug where deleted search results might not disappear from the listview
-Added customizable BPNext address; sometimes the code handler would run multiple times in a frame, so if you can find a more reliable address now you can use that instead
It's been a while since we've had an official build, and the the vanishing code bug is a showstopper, so unless someone finds something else wrong with this in the next couple days it's going official 0.62.
mh i found a bug, but i dont know from what ???
the wiird.dot.net works but when i send cheat codes few seconds later game frozen
(http://www.bilderhoster.net/safeforbilder/8mky4y8n.png)
i dont know from what hmmm... when i start the normal wiird works fine.
i think a code intepretation error by reading data? :eek:
Ozelot post in the right area -.-
Bugs and requests for geckoDotNet are found here:
http://wiird.l0nk.org/forum/index.php/topic,4954.msg53005.html#new
post in the right area next time.
when changing the selected code in the left pane, you want any changes in the right pane to be stored to the code. when dragging and dropping, there was temporarily an extra item in the list, and it was changing the selected code at the wrong time so that it thought the old item's right pane was what you wanted to be stored. A relatively simple fix that took quite some time to isolate...
So...assuming that no one else finds any other bugs...this will go 0.62 soon...honest! ;)
test build r78 (http://www.mediafire.com/?aj4oxghcmmj)
btw, since I'm already making a post...Ozelot, check to see if "Pause While Sending" is checked. I can imagine how that might cause problems. But don't post back here...take it to the bug/request thread in my signature.
You still haven't fixed the register display
He's not exactly getting paid for this so easy on the demands, maybe appreciate the HUGE advancement it's been through
Not trying to come off as demanding but it's a pretty big problem, I don't think a new official release should be made until it is fixed
Cosmetic bugs that only affect the appearance of data are not nearly as catastrophic or annoying as bugs which get rid of codes. You can still use Text View, even if it looks funny.
First and foremost is the protection of a hacker's prized possessions - the codes - and everything else is secondary to that.
The Text View shouldn't be too hard to fix, though. Since you're such a nice guy I'll try to make sure it's adjusted before 0.62.
test build r80 (http://www.mediafire.com/?nltnmxl1xt3)
-Text View Breakpoint Register window no longer wraps around
-All (most?) of the popup windows should now center above the parent when they become shown
Changes since 0.61; see this post http://wiird.l0nk.org/forum/index.php/topic,4886.msg46432.html#msg46432
All TextBox's that had an address are now special AddressTextBox's. What does that mean for you?
- They check the validity of their inputs. If the address is not valid, the background is colored a faint red.
- They prevent you from entering non-hex digits
- They support history. All of the history functions are available from the context menu. In addition...
-- Double-click to show history
-- up/down to scroll through history
-- Ctrl+Enter adds the address to the history
-- Ctrl+Delete removes the address from the history
-- Ctrl+Shift+X to cut all history addresses into the clipboard
-- Ctrl+Shift+C to to copy all history addresses into the clipboard
-- Ctrl+Shift+V to paste all history addresses from the clipboard
-- Ctrl+Shift+Delete to clear the history
-- Enter/Click on a history address in the dropdown to select it
-- Delete on a history address in the dropdwon to remove it
-- Auto history checkbox in context menu will add any valid address to the history when the textbox loses focus. This is enabled by default
- All (hopefully) dialogs should pop up centered above the app
- sleep(100) after gecko.Pause() because otherwise it doesn't seem to work
- eliminated hex->float rounding
- Connecting can now be canceled
- Added customizable BPNext address; sometimes the code handler would run multiple times in a frame, so if you can find a more reliable address now you can use that instead
Search:
- Search comparison type dropdown lists all options without a scrollbar
- Loading search sets "last value" correctly
- MessageBox when there are no search results
- Poke initialized with old value
- Fixed a bug where deleted search results might not disappear from the listview
Memory Viewer:
- Just about everything that selects a new Memory Viewer address will center that selection
- Pageup/Pagedown work in the Memory Viewer address text box
Breakpoints:
- Fixed conditional branch detection bug (less than and equals were backwards)
- Register Editor Dialog comes up on top if needed, textbox is given focus when shown
- RegisterDialogBox exception fixed
- Show Mem supports lhz
- BPCondition context menu - Copy, SRR0 !=, SRR0 ==, Delete, Clear
- Delete key works in BPCondition list
- Rearranged Breakpoint Tab so that Active Conditions is resizable
- Active Conditions now has a checkbox to enable/disable conditions
- Breakpoint Condition Value register is now updated with the current selected register's value:
-- on a breakpoint
-- on a step
-- when the current selected register dropdown is changed
--- This was designed primarily to make SRR0 != conditions easier to set (i.e. "don't break on this instruction"). But it should make all conditions easier.
- Breakpoint Group Conditions
-- all conditions in a group are ANDed, but all groups are ORed. Only one group needs to be true, but all conditions in that group must be true
-- Breakpoint group number is prefixed to the condition in the ListBox
-- To change condition group number, select conditions to change, right click, Set Condition Group, enter the new value and press enter
- Copy All breakpoint conditions, and a separate Copy for just the current condition
- Paste copied conditions into the list
- Step Until; will repeatedly Step Into until the Breakpoint Conditions are met. Can be canceled
Disassembly:
- Disassembly context menu can now Copy all of the disassembly to the clipboard
- Disassemble() properly closes FileStream
- Enter key in one-line assembler emulates clicking Assemble
- Fixed one-line assembler problem with bctr/bctrl/blr
GCT Codes:
- Fixed bug where reconnecting could cause codes to be lost
- Fixed bug where drag/drop could cause codes to be lost
- Generate the cheat stream like WiiRDGUI does; appears to have fixed some Send Cheats bugs...?
Watch List:
- Watch list updates faster. Still slower than Memory Viewer, but should be more tolerable now
- Fixed Watch list random exceptions
test build r82 (http://www.mediafire.com/?nyjoji5iz4t)
- Breakpoint Register Edit View will show float registers as floats. Text View still shows their hex values
- Adding Breakpoint Step logging
-- Click on the checkbox to specify the file to save the log to
-- On a breakpoint or a step, the address and its instruction are written to the log file
-- In addition, the values for each register used in the instruction will be appended to the end of the string
-- Specifying a pre-existing file will append new values to the end, so you don't have to worry about over-writing and losing your log
-- The log is flushed after each instruction is written, so you can read it while it's being written to
-- To clear the log, first uncheck "Log Steps" to close the log, then you can delete all the text and save, or just delete the file
Breakpoint Step logging! :O
*claps hands in joy*
That breakpoint logging is frikin epic mate! Thank you!
test build r83 (http://www.mediafire.com/?zjjwmheymm3)
- All AddressTextBox should REALLY be autohistory by default. Honest. For real this time!
- bl/blr will indent the log to help highlight function calls. set breakpoint will remove all indenting
- instructions are padded so that the detailed log information is always lined up nicely in Windows Notepad
- properly detects float registers when logging (before, a branch like b 0x800f060 would have confused it by making it look for float register 060)
- for load/store, the address is written to the log, as well as a peek of the current value at that address
- Conditional branches now add a row of "..." when they are taken, to highlight the changing instruction's address
The logging feature is very useful with Step Until SRR0 == X. Start at the instruction you want, pick the ending instruction X, and when you press Step until it will repeatedly go through and record just about everything for you.
test build r84 (http://www.mediafire.com/?uzznog4hwzh)
- Conditional blr's (beqlr/bnelr/bgtlr/etc) now un-indent the log
- bctrl now indents the log
- b branches now also insert a row of ... into the log to highlight the changing address
- When indenting in the log, there is now one column of |'s per indent, to help keep track of depth
- Step Over and Step Out now preserve the log's indent
- Step Until will clear the Active Condition Checkbox after it is done stepping so you don't accidentally leave the checkbox checked and miss a breakpoint
- Conditional blr's are now caught by Step Out
- Gecko.NET will try to quietly reconnect once before prompting the user to reconnect. this probably doesn't work on searches...yet...but it will work for Step Until
- Added MemView modes: Single (shows everything as a float), and Auto (tries to guess what it should show the value as). Auto Zero will show 0 as 00000000, while Auto Dot will show 0 as . . . .
Seriously, the Auto MemView Mode is pretty cool. Hex, Singles, and ASCII all in the same Memory Viewer screen. I personally prefer Auto dot mode.
Well that's a cool idea! That'll be fun to see when all of them are in the window, and especially helpful when hacking objects.
yeah, nice feature, will test it out.
betta-y goodness (yum)
already having to figure out which i like more.. GUI looks a little more streamlined and graphically "pleasing" but just with a preliminary overview.. i can easily see i will be using both extensively!! favorite thing ive noticed so far.. the ability to sort (by value) the various address results ie. the values each address holds! very helpful for getting fast general ideas of what to look for and not to look for if you know a range ;)
Okay, so the next feature to develop is improving the search support. My test case is to pause the game so no memory can change, and then do an Unknown Search, and then an Equals search, first on MEM1 and then on MEM2. The MEM2 search will create the largest possible files, and Gecko.NET must be able to handle files this large.
If you've ever tried to work with very large search results, you might have noticed that it's a little slow, especially if you tried to save a search to a file. As it turns out, Gecko.NET reads the dump from Gecko OS into a MemoryStream. It then does the compare against the MemoryStream (or MemoryStreams, is you're comparing against last value), and creates a List<> of type SearchResult, which has fields for address, oldValue, and newValue.
Serializing a List<SearchResult> to a file of a complete MEM1 unknown-equals search results in a file that is 159 megabytes. :eek: That is huge...no wonder saving a large search is slow.
So I tried looking into compressing the stream before writing it to disk. The results were good and bad...my dual-core Windows XP machine with 2 GB of RAM took 20-30 seconds or more to compress the results and write them to disk, with CompressionLevel set to BestSpeed...but the file size was 48 MB, which is an incredible compression ratio of more than 3:1!
This research leads me to believe that the problem is the List<SearchResult>. The data structure is just too large. It's also redundant; most of the time, the MemoryStream that has the search dump is still lying around while there are duplicate values in the List! So I think I'm going to partially gut the search function and re-write it.
The plan is to replace the List<> with a standard UInt32[] that just holds the addresses of the successful results. And instead of copying search results into the List<> I'm going to read the values directly from the original dump, so they're only in one place in memory. Then, I'm going to populate the search results' ListBox with values derived from the UInt32[] and the dumps.
After this, there are a lot of neat new features that will be easy to implement. For instance, I will see if I can populate the search results' ListBox while the search is transferring. I can also make it so that dumps can be paused and restarted. I can compress the search dump behind the scenes while it's being transferred. I can then store pre-compressed dumps to disk to provide an Undo mechanism. I can also store many pre-compressed dumps, to provide a multi-level undo. The multiple dumps can also act as a multi-level history, so you can not only see NewValue and OldValue, but SecondOldValue, ThirdOldValue, etc. This also provides opportunities to extend the search comparisons from "specific value" and "last value" to include "first value" or "nth value".
So...this might take a while...and the searching could get a little buggy for a few releases while I work the kinks out of the new system.
That sounds awesome man! Are you using any specific compression algorithm?
Whatever DotNetZip (http://dotnetzip.codeplex.com/) uses. It probably depends on what you set the CompressionLevel to, but I think it uses GZip. It's free and open source, and that's what I care about the most. ;D
I would use the built-in GZipStream in .NET but I hear it's really crappy, and it's possible to embed a dll into a .NET assembly using ILMerge anyway so I don't even have to worry about distributing another file.
And DotNetZip is also Mono compatible, for whenever I decide to go for round 2 on the Mono thing...
Auto MemView is amazing! Very helpful when the game uses ascii in the code. In the Call of Duty games you can actually get C++ code out of the memory :P
It would be helpful if I could upload stuff using geckoDotNET though... WiiRD can do it (not GUI). So why cant you make on option to open the console? It'd be very helpful if I could dump and upload the modified C++ files from the games :) *hinthint*
Eventually I'd like to color-code cells according to their suggested data type. However, I think Auto Mem View will probably need some tuning. Here's how it works.
Anything that's a valid pointer will be shown as a hex value.
Anything that's not NaN, and whose absolute value is greater than 1e-7 and less than 1e10, will be shown as a float.
Anything that has four valid ASCII characters (0x00, 0x20 -> 0x7F) will be shown as ASCII.
Everything else is shown as hex.
The tuning would involve modifying the upper and lower bounds for what is considered a float. I chose those numbers because they're smaller/larger than the practical values that you normally find floats used for; some games probably use three or four digits past the decimal, but not seven. Also, some games use millions or billions, so I set the float cap at a trillion.
I think it also needs some ASCII tuning, too. For instance, four valid ASCII characters, but 0's cannot be a leading character, only trailing. So 0x39310000 would be treated like ASCII, but 0x00393100 would not.
EDIT: oh yeah, hetoan, look at Gecko.NET's memory viewer's context menu. There's an Upload menu item that I never looked at. It might do what you're asking.
Any chance getting pointer search for Gecko.Net ? A separate program will do if pointer search is not possible to be added to our lovely Gecko.Net. I just can't stand Wiird anymore. Crashes like crazy. 8)
1e-7 is a little too small.
I have never seen a floating point used that was below 1e-4
The hexadecimal cod 35320000 gives a floating point of 6.6e-7 even though it is for the ascii "52"
Also in the very first area of mem1 there are values stored to certain addresses that always hold a certain value. Like at $8000000 the title ID is stored and at other values stuff like FST and whatnot is stored. These addresses always have the same type of value, so i'm suggesting that for those areas that they always be shown how they were meant to (ascii for ID and plain hex for FST, etc.)
Here's a link to the memory map in case you want to implement this (or fix the FST :\)
http://www.wiibrew.org/wiki/Memory_Map
Also thanks for telling me about the upload function, it should be helpful. Although command lines are a lot easier to copypasta from a txt document :(
Ideally, there would be a separate file which stores the data type of each memory viewer cell. So that way, if auto guessed wrong, you could tell it that it's wrong. But that might be a bit complicated.
Will the color coding be optional? there's plenty of room on the tools & about tabs to put some options, and it might be distracting to some people
wiiztec - Color coding, if I ever did it, would be optional. I might even make it programmable, if you don't mind trolling through a text config file and changing values there.
Mokuro - I don't think I will ever personally work on a pointer search mechanism. I don't see the point, really, when you can just use a read or write breakpoint and find the offset without wandering through various levels. Or when you can use a C2 hook and get around the whole pointer problem.
After re-working the search code, my next goal will probably be integrating PyiiASMH-like support into the GCT Wizard.
hetoan - I will consider making the thresholds for float programmable (probably via text config file). I wasn't sure what the smallest/largest practical float is, so I decided to go with things that were a few orders of magnitude smaller/larger than the smallest/largest things I've ever personally seen.
I will also consider more ways to appropriately recognize ASCII (for instance, "is the previous memory word ASCII? If so, this memory word is more likely to be ASCII")
sounds like it'll be good. txt config files for colors and floats is good with me :D
That sounds great, dcx2. Thanks a lot for the tip and Keep up the good work. :cool:
test build r85 (http://www.mediafire.com/?mkejatgbmyz)
This is more beta-ish than normal. I reworked searching over the past two days to get it a little cleaner, so I may have missed some things in testing. To entice you to try this, I give you...
Undo Search!
I also added some logging. It writes to a GDNdebug.log file. Right now, it only writes some exceptions and the time it took to do sorting. Sorting by address is fastest, sorting by value or oldValue is about 6 times slower, and sorting by diff is 10 times slower. So if you have hundreds of thousands (or millions) of results, sorting will take a long time...sometimes minutes.
It should be easier to add more search functionality now. Memory usage should go down some, too. Until things get straightened out all the way, loading and saving is disabled.
I just want to once again thank all those that have been working on Gecko.net.
Even though I've not been posting that much I have still been following this thread closely and downloading the releases to use when I get the time (not had much in the way of time for posting or even hacking lately).
This app has, and still IS, turning into something truly amazing and is already more than anybody could have hoped for! Purely phenomenal additions and functions!
Please keep up the good work guys :cool:
test build r86 (http://www.mediafire.com/?kh4m2zj1ymn)
- More exceptions will be written to the log, as well as more timing info
- canceled searches will populate the search results with whatever it managed to transfer
- Search History!
---
Search History is controlled by the two new NumericUpDown spinners labeled New and Old. Every time you do a search, the results are compressed and saved to disk in the background. A full MEM1 compressed search takes up about 10 MB or so, so you should be able to do hundreds of searches even if you have limited space.
If you change the value in Old, the Old and Diff columns will be updated with that search's values. You can use this to see how a value is changing over the course of multiple searches.
If you change the value in New, the New and Address columns will be updated with that search's values and the matching addresses. This is just like a multi-level undo, because you can go back to any search in the whole history. If you do a search after going backwards, the new search will be added to the end of the history, so you never lose anything.
It is possible for New Value to point to a Search History index that is less than the Old Value index. Older New searches can sometimes have more addresses in the dump than newer Old searches; if this is the case, you will see "N/A". I think the way Block Search works, any value that was "skipped over" by a block search will probably have a 0 instead of N/A.
---
Potential areas to improve:
- Sub folder for search history so it doesn't clog the main folder
- Make skipped over values = N/A
- Ability to turn history on/off
- Not sure what happens if you get 0 results...it might erase the history, which would make it hard to undo
When does this message appear? Before the GUI loads? After it connects? Do you see anything in GDNdebug.log?
That sounds like an XML error. There are only two of those, and they should be created if they're missing...maybe yours are corrupt?
You could try renaming gecko.xml to gecko.xml.bak and Gecko dNet.exe.config to Gecko dNet.exe.config.bak while the program is not on, then run it again and see if you get the same error. Try gecko.xml first.
re: multi-poke...I just tested it and it does work, but I didn't have the XML error that you do.
Oh, by the way, regarding Search History...
When you do a search against "Last Value", it will actually search against whatever you have set Old Value to. So you can in theory compare a dump against any value in the whole history of your searches, even the first search. Might help with things like the GLEE method.
The values are currently 999...I will make them initialize to 0 in the next build.
0 means no search is loaded.
Remember that the search history also includes each result list for each search. Older new searches will have more results. You could in theory use this to fork a search, scrolling New back to get the other list and scrolling Old back to compare against the correct older dumps...you'd just need to keep track of which dump numbers correspond to which searches.
After thinking more carefully, "Last Value" is actually comparing against the New value (which *becomes* the Old Value when it's time for comparisons).
I'll rename "Last Value" to "New Value" and I'll add an "Old Value" line too.
Huh? Last value makes sense to me, it's the value immediately preceding the incoming future value, renaming it to new value doesn't make sense to me as it's actually the same thing as what you call the old value.
Yes, there is a bit of a naming conundrum. You're thinking about what it is like *after* the dump transferred. The problem is that you hit the Search button *before* the dump transfers.
Before you hit Search, the dump that will become "Last Value" is currently "New Value". When you click Search, the current New Value dump becomes the new Old Value dump and *that* is what the comparison is run against. That is why, at the moment of clicking, "Last Value" actually corresponds to "New Value".
The problem is that if you scroll back the New index, it's more like undo...you will load previous search result addresses that have since been culled. So you can't actually compare an incoming dump against the first dump. This is why we need an Old Value in the dropdown; so you can load previous searches without loading their associated address result list.
EDIT: Perhaps "Last New" and "Last Old"?
How about "current value" before you click it's the current value, when you click it becomes the last/old value
Okay, so if we want to compare a search against the values currently in the New column, we would specify "Current Value".
What should we specify when we want to compare a search against the values currently in the Old column? Still "Old Value"?
We're comparing values in RAM to values in one of the columns, so number the columns and compare column X to Current RAM. Something like that.
*shrugs*
The problem with numbering or otherwise annotating the columns is that they lose their New/Old semantics. If you just see column 1 and 2, or A and B, you don't easily know which column has the values that just got dumped from RAM.
The problem with "current value" is that if you change the New column then you no longer have the "current" value, but instead you have an older value in the New column. Remember, the results in New can be older than the results in Old.
I would like to have consistent wording between the numeric updown spinners, the search result columns, and the compare-against dropdown box, if possible. They are all directly related. To that end, I think I'm still leaning slightly more toward "Last New" and "Last Old", or "New Column" and "Old Column". However, I'm still very open to suggestions, including different column names.
...maybe I could even add another item to the dropdown list..."Diff Column". So you'd have four; specific, new, old, and diff.
test build r87 (http://www.mediafire.com/?mm4qnnz1gtz)
- Improved Search History
-- Replaced "Last Value" with "New Column (n)" where n is the number of the dump currently displayed in the New column of the search results
-- Added "Old Column (n)"
-- Added "Diff ([n+1] - [n])"
Old column searches can be used so that you aren't reloading culled addresses.
Diff searches can be used to find timers going in a specific direction. For instance, if you do a Diff search for values equal to FFFFFFFF, then you will find only down-counters. A different-by-1 search would find both up and down counters. There are probably other uses I did not consider.
I'm still up in the air about the naming convention. I'm leaning toward wanting to modify the column names more now. Maybe replace Old and New with Dump(n). I could even add (n) to the end of address, to highlight that the list of addresses corresponds to the nth search.
test build r88 (http://www.mediafire.com/?e52monmtgn5)
- Dramatically rearranged the layout of the Search tab
- Search Comparison Groups!
There's still some fine tuning needed, but this should be stable enough for people to try out.
Recall that there was once an "Upper Value Info" box that acted like a sort of second comparison, but only supported less-or-equal searches. Well...that's gone. With Search Comparison Groups, you can have as many search conditions as you want (up to 9999), and they can be any type of comparison and not just less-or-equal.
So, for instance, with a Specific search, the first group could be "less than 0x64", the second group could be "greater than 0xFFFFFF9C", and the third group could be "not equal 0". This would find all addresses that are between 100 and -100, excluding 0.
To find timers, with an Unknown search, you could make the first group "different by 1", and the second group "less than" to find down-counting timers or "greater than" to find up-counting timers.
---
This is still under active development. I plan on making it so that the comparison source dropdown (specific/new/old/diff) is part of the comparison info. So then you can do a simultaneous specific search and unknown search.
I also plan on making it so that only one specific-equals comparison will need to be true (so you can test for equals 0, or equals 0x64, etc), or all the other non-equals searches will need to be true.
That is so epic! Thanks a million!
WOW.....
The search comparison groups are going to be a true god-send.
I cannot tell you how many times I have had multiple thoughts on looking for a specific address/value...and you have just solved that dilema! Do all search methods...at the same time ;D
This is going to shave so much time off code searches. Thank you so so much, dcx2!!!
test build r89 (http://www.mediafire.com/?ji0kymohtht)
- Rearranged search tab some more
- added specific/unknown/old/diff as a per-group item
- Search group behavior works as follows now
-- Any successful equals comparison automatically wins
-- All other comparisons that aren't equals must all be true to win
This allows something like "(equal to x OR equal to y OR equal to z) OR (greater than a AND less than b AND not equal c)"
There is, however, one exception. Suppose that in the above example, a < b. This would mean a value between a and b. That's actually possible in this case.
However, if a > b, then there is no way to have a value that is both greater than a and less than b; the ranges are mutually exclusive. In this case, it will allow a greater than to fail if there is a successful less than, or vice versa. This allows you to search a sort of inverted range, like my example above about x < 100 or x > -100 and x != 0...that won't actually work in r88, because FFFFFF9C > 64, and you can't be bigger than FFFFFF9C and smaller than 64.
test build r90 (http://www.mediafire.com/?n5eezzn4mzy)
- Search dumps that are interrupted by an exception will now be continued once it reconnects. I tested this to make sure that it doesn't miss any data. You can even unplug the USB Gecko, plug it back in, and pick up where the search left off.
- Disable search comparison type combo box when Unknown searching
- Search Groups groupbox now lists the total number of search groups in ()'s
- Search Groups indices now start counting at 1
- When no search results are found, you will be prompted to undo or restart, instead of automatically restarting with no chance to undo
The compressed search history requires Ionic.Zip.Reduced.dll (http://www.mediafire.com/?ddznjnqzjwj). I plan on including this in the main executable in the next build.
Any chance of getting an updated source code package? The latest one available is 0.61.
Yes, certainly. I will make r91's source available, and it will include the zip library and the ILMerge thing to integrate the library into the executable. (that part will be fun! and might be a headache to port to mono, but fortunately it's not a requirement when building from source)
test build r91 (http://www.mediafire.com/?0f8mub9ziyezgrb)
- Cheat stream bug fixed; no more weird behavior on SMG1, etc
- Includes Ionic.Zip.Reduced.dll
- Fixed 16- and 8-bit search dump crashes that are the result of some recent changes
- Protect against some rare problems in the disassembly tab
Source is updated to r91.
awww shit, fuck, fail!!!
Geckodotnet freezes for example pokemon battle revolution if you apply ASM Codes!!!
I tried with Wiird and worked fine! :eek:
Please fix that, WiiRD still rulez, because it can hack everything, not like geckodotnet... :rolleyes:
Wow...first, you're not even in the right thread. Not only is the link to the bug report thread in my sig, but it's also in the first post.
Quote from: Link on January 03, 2010, 01:33:37 PM
Bugs Reports/Feature Requests here: http://wiird.l0nk.org/forum/index.php/topic,4954.msg46053.html#new
Second, if you wanted my help with your problem, then disparaging the software that I develop
in my free time is not going to make me want to help you. ::)
Third, even if you hadn't been offensive, the only detail you provided is "pokemon battle revolution" and "apply ASM codes". There are way more details that I need...
...and I'm not going to tell you what they are. If you want your problem fixed, go download the source and fix it yourself. :mad:
I'm glad that it freezes your game. Twits like you make me want to stop working on this app, or keep the updated features to myself instead of going through the trouble of making release notes or taking feature requests. :mad:
sorry but bully is right!
geckodotnet break on some games wrong.
your methode to disable C2 codes via pausing the game will not work because C2 will be permament written to RAM! you can't change it back.
BUT don't stop working on it.
it's a really nice hacking tool and I think these bugs can fixed easily.
btw bully try to code it yourself if you can it better :rolleyes:
It's not WHAT you say...it's HOW you say it!
Yes, Bully probably is right and there is an issue in the method of applying C2 code types in Gecko.net, but he needed to provided details on the problem.
I LOVE Gecko.net. YES, there are certain issues that may crop up with it but it's ALWAYS in the coding stage - dcx2 is donating his free time in the development of this tool. Remember that GDN has a few more complex features than Wiird, and with this comes the potential for some issues to arise...
Help him to help you by providing the details required in hunting down and rectifying the issues that you hackers might come across.
I have complete confidence that the developers will find and fix these bugs...you just need to let them know the specifics about them ;)
it´s NOT your version of geckodotnet,which "fails" I mean generally geckodotnet...
Sorry for being impolite in my last post, but why the hell is an updated wiird worse in some parts? The search is awesome and fast, most things aswell.I mean, why does the game instantly freeze, when I apply a C2 code with geckodotnet, but with WiiRD it works fine? :)
Can´t you use the same "appying codes" like wiiRD?
I only wanted to provide some details for bugs, which you requested with your signatur, that´s why I posted, I wanted to do you a favor in bug reporting... You are angry now, ok, but people won´t be happy with C2 bugs though. :rolleyes:
Enough for now... I just shouldn´t mention such things, if it´s better then. :P
Fuck that, you're banned. You can NOT get away with such disgusting and disrespectful language towards respected hackers here.
lol with gecko dotnet, the game doesn't freez anymore by activating C2 codes more times!!!! :eek:
nice work!! :D
btw is it possible to change the size on memory viewer?
this would be nice^^
dont quit dcx2!!! :( gecko.NET is very helpful ;) its a very nice and easy to use layout on it. dont give up because of the annoying noobs.. we still need people working on these kinds of programs :( id try learning the language to do it in order to help.. but im kinda lost right now just dealing with the ram and asm coding lol
Aw, shucks. ;D You didn't need to
ban him...Mokuro did the same thing a few pages back (posted a bug report in the release thread, did the rolly eyes thing). If he wants to multi-fail (wrong thread, rude, no details), then I'm fine just ignoring him. Thanks for the thought, though!
To others...I doubt that I would quit, because most of the features I put in are things I want to use. I'd probably keep adding features for myself. But shit like this makes me sympathize with bushing...on the hackmii blog some idiots were whining about the fact that TT was taking their time to release, and he was like "well do it yourself if you're so impatient".
As far as C2 freezes...I write almost exclusively ASM codes, so you think that I might notice that sort of problem sooner or later. Now, I only have about eight games, and I've used Gecko.NET to hack most of them, but there was an elusive bug that messed up the cheat stream that r91 finally fixed. I didn't have anything to do with the USB Gecko, Gecko OS, or WiiRDGUI - they were all made before I even owned a Wii - and there's no documentation anywhere that I know of, aside from the comments Link left in the source code.
Quote from: Bully@Wiiplaza on July 27, 2010, 05:41:49 PM
I only wanted to provide some details for bugs, which you requested with your signatur
Why oh why do you fail so hard? This is the release thread. The purpose of this thread is to document new releases and what their changes/features are. This is
NOT the bug/feature thread.
And even if it
was, you still didn't provide any details. You applied C2 codes...I do that all the time. If you can't give me enough details to find or reproduce your bug, then I can't help you (and that's assuming you were polite in the first place). It works for me on my games.
test build r93 (http://www.mediafire.com/?bn078dzpewnx6pf)
-Search result context menu GCT code now loads the value from the New column as the second half of the code, instead of 0
-Added Show Mem support for many more memory instuctions...this should be all of them now
-Show Mem now has a context menu, which shows the memory address and its value when you right-click, and the "label" can be clicked to put that value into the clipboard
-Added "Set SRR0" to disassembly context menu; use this to move the "current instruction" pointer while at a breakpoint or stepping
-ctrl + a in the GCT code text box will select all the text
-AutoHistory should FINALLY default to true!
---
Assuming there are no major flaws in this, it will probably be promoted to an official build in a few days because of the cheat stream bug that was fixed in r91.
test build r94 (http://www.mediafire.com/?r4xyf4bi7g1zfdr)
- No more dependency on Ionic.Zip.Reduced because the dll is now merged with the exe
- Search history is stored in a sub-folder to decrease clutter
---
As mentioned before, this is going official in a few days, so I would appreciate any (polite!) feedback
test build r95 (http://www.mediafire.com/?qnd8yj568tkp54j)
- Temporarily disabled indexed load/store support in Show Mem (i.e. stwx, etc).
test build r96 (http://www.mediafire.com/?dt87ancry7ysaej)
- Fixed breakpoint branch toggle bug
- Added support for stfd/lfd to Show Mem
- Added support for indexed memory accesses to Show Mem
- Fixed potential breakpoint bug?
- Fixed potential search bug?
- Improved support for logging float register values
- Step Out context menu
-- Clicking on Step Out will behave like normal
-- Right-clicking on Step Out will show three options
--- Walk to blr is exactly the same as clicking on Step Out. It will repeatedly call Step Over until a blr is encountered. It is the safest way to find the caller.
--- For functions that do not create stack frames, use Leaf. It will set an execute breakpoint at the address in LR. However, if the function has a stack frame, leaf will get lost.
--- For functions with a stack frame, use Stack Frame. It will parse the stack and set an execute breakpoint on the address in the LR Save Word. However, if you use it on a leaf function, it will actually step out *twice*.
- Search disassembly with regular expressions
-- If you don't know how to use regex, google it. wikipedia is a good resource. http://en.wikipedia.org/wiki/Regular_expression#POSIX_Basic_Regular_Expressions
-- If you don't care about regex, this should work pretty much like you might imagine, except that certain symbols will need escaped. If you want to use these symbols \*+?|{[()^$.# then you need to place a \ in front of it
-- So to match r29, just use r29
-- To match (r29), you will need to use \(r29\)
--- regex is very powerful. Let's say you want to look for stwx. Just enter stwx.
--- Let's say you wanted to find stwx, or sthx, or stbx. stwx|sthx|stbx
--- Let's say you wanted to find any indexed instruction. You could start with just x. But any address will have an x, as part of the 0x. So you could match any x that doesn't have a number from 0 to 9 immediately after it. x[^0-9]
--- Then you find an 0xf somewhere. So you want to match x that doesn't have 0 through 9 or a through f immediately after it. x[^0-9a-f]
--- Then you find an xoris somewhere. So you want to match instructions that begin with l or s, followed by one or more letters a-z, and then an x, with no 0-9 or a-f immediately after the x. ^[l|s][a-z]+x[^0-9a-f]
--- That will now match lwx, stwux, stfdx, and so on.
wiiztec asked for disassembly searching a while ago. Here you go buddy. ;D
test build r98 (http://www.mediafire.com/?qrsryq45mmn7dyh)
- MultiPoke improvements!
-- When adding search results to MultiPoke, it will now show all the search results in the History dropdown for the Poke address text box, so you can see what addresses are being MultiPoked.
-- The addresses in the History can be copied and pasted to and from the clipboard, so you can save and load MultiPoke lists.
-- When you click Poke, if the Poke address text box is "MP", then it will poke every address in the History.
-- You can now multi-poke without doing a search, by manually adding items to the Poke address History.
-- If there are values you want to remove from the MultiPoke list, just delete them from the History.
- Disassembly search window is now 1000 instructions, up from 85, now that I figured out how to properly redirect standard output from vdappc...
- Disassembly view shows more lines now if you stretch it out really tall
- Notepad no longer crashes when there's no game name
- When unchecking the Slow checkbox on the About page, it will remember whether the game was paused or running
-- So you can be running at full speed, then switch to 6 FPS to get to some point you want to get to, and then slow it down even more to 0.5 FPS if you want, and when you uncheck Slow, it goes back to running at full speed
-- If you were paused, and stepping through one frame at a time was taking too long, you could set it to 6 FPS and then click Slow, and when you got to the point where you want to go frame by frame you can uncheck Slow and it goes back to being paused so you can now step through frame by frame to the point you want.
---
I also thought up some more good examples of disassembly search regex's.
Let's say you saw that Mario can do a second jump whenever a certain address has a 2 in it. So you want to look for any li that loads a 2 into any register.
1) Start by looking for li
2) Make sure you look for li at the beginning, so we need the ^; this gives us ^li
3) Make sure to ignore lis by using [^s], which means do not match if there is an s. So far so good ^li[^s]
4) We want to find the li that is loading a 2. It doesn't matter what register. So we use $ to match for the end. ^li[^s]2$
5) However, that's not going to work. Because it wants to match ^ = beginning, then an l and an i, then anything that's not an s, then a 2, then the end. However, we need to match all the crap between the li and the 2. That's achieved by using . to match anything and * to match anything at least 0 times. This will absorb all the junk (space, comma, register) between the li at the start and the 2 at the end. ^li[^s].*2$
6) But then you end up finding things like li r0,102, so you make sure to match a , before the 2. ^li[^s].*,2$
Or maybe you want a timer. Look for addi or subi with a 1. ^(addi|subi)[^s].*,1$
you are saying we can search the registers/functions now for when they are finally called on? :O when i get my gecko working again... im switching to finding all my codes with your app!
I'm not sure what you mean...
Imagine copying and pasting a thousand lines of disassembly into Windows Notepad, and then using ctrl-f to look for certain strings like addi. Well, ctrl-f is pretty weak in terms of string matching power...which is why I suggest using regular expressions, so you can parse out exactly what you're looking for.
You can't search the contents of any registers. You need to use breakpoints for that. But if something interesting is in r28 and you want to see what instructions referenced r28 nearby, then yeah you can search for r28.
sorry for being confusing as usual.. lol yes basically that :P your free-time-project is getting pretty darn awesome there ;)
dcx2 for president ;D
lol
thanks dude appreciate it you are updating on a regular base
test build r100 (http://www.mediafire.com/?mnaqbyta0k420od)
- Save and Load search histories
- Serial Poke!
-- Load up a bunch of addresses like you were going to multi-poke
-- Put the first address into the Poke address text box
-- Click Serial Poke. That address will be poked, and the Poke address box will load the next address from the history
For instance, you can search for 3F800000. Then load all those results into the multi-poke list. Then, instead of all at once, you can Serial Poke each one, one at a time. Just spam the Serial Poke button, and whenever you see something's size change, double-click on the history and go back a few to find the address you're looking for.
---
Also, one more example on how to use the new Disassembly Regular Expression Search. Let's say you're looking for a branch to 0x80123440. You could just enter the address 80123440. However, sometimes a branch will actually land *near* that address, like 0x8012343C or 0x80123438. So you want to look for 8012343C as well.
801234(3[8C]|40)
D: ohnoes not serial pokers >_<
but in all seriousness that feature sounds amazing and i kinda wish i had it in teh past :S
I honestly think the disassembly search is way more powerful and useful, but after making multi poke based on the address text box history, serial poke was ridiculously easy to add. And Romaap did ask for it a while back, too.
well fine then just go and make the best tool ever why dont you :P and dang you are good at it too lol
test build r102 (http://www.mediafire.com/?c3q1q7i0oftoru8)
- increased Memory Viewer Search character limit to 256
- added Hex to Memory Viewer Search Types (good for finding unique Z values for F6 codes!)
- Added "Copy Function" to Disassembler context menu. This will try to put the whole function into the clipboard, instead of just the visible disassembly.
Has anyone been testing these features (Serial Poke, Step Out context menu, Disassembly search)? I see there's about 5-10 people who appear to be downloading the test builds.
I am one of them, but haven´t tried out these features yet.
Can´t explain it well now. :confused: I selected multiple adresses and clicked serial poke and it gave me an error.
And thanks for adding more characters search, worked fine :p
test build r103 (http://www.mediafire.com/?lyldpnawxxq59q2)
- Added HistoryTextBox to Disassembly selected address value
-- When Assemble is clicked, it stores the original address/ASM in the history for you automatically; double-click to show so you can "undo" your ASM edits
- Added SRR0 != and SRR0 == to Show Mem Context Menu
- Added Show Mem Context Menu to Step Into and Step Over
- Changing the Show Mem Context Menu value will poke
I know some people have asked for ASM edit history.
I think wiiztec wanted those last three near the Step buttons so you don't need to move the mouse as much while stepping through.
test build r104 (http://www.mediafire.com/?noirsyn2z1enj9y)
- Added "Regex Search" checkbox to About tab
-- When Regex Search is unchecked, the Disassembly Search is literal, so you don't need to escape it
-- So (r29) would match (r29)
-- When Regex Search is checked, the Disassembly Search will use Regular Expressions
-- So \(r29\) will match (r29)
Since regular expressions are difficult for even most programmers, I decided to make the search simpler, with the option of using regex for those who can use it. The default is Regex Search unchecked.
test build r105 (http://www.mediafire.com/?sfdvjc7hh7ss3u2)
- Fixed bug where disassembler would crash when assembling an instruction that was less than 8 characters
-- This bug was introduced with the disassembler history and did not affect previous versions
test build r106 (http://www.mediafire.com/?t9jj8jcvgrvw391)
- when a code is entered into the GCT textbox that does not have enough hex digits, it will pad 0s instead of returning a blank code (fixes one a Bully bug)
- when a code is entered into the textbox and then immediately dragged, it now updates the code before beginning the drag (fixes another Bully bug)
- when dragging a code, the dragged code remains selected when the drag completes; previous behavior had no selected codes after drag completes (this one's on me! ^_^)
- fixed case insensitive Memory Viewer search; previously, only the case sensitive searches would work (third Bully bug)
I'm not ignoring requests. But it's a holiday weekend in the US. I will get to them later. For now, here are bug fixes.
test build r107 (http://www.mediafire.com/?1huc2p5k49cy33k)
- Added Memory Viewer Font Size text box to the Memory Viewer Grid Context Menu (for Bully)
- Memory Viewer Grid cells now automatically resize to show their contents without an ellipsis (for spunit)
- Added View Floats as Hex checkbox to the Show Mem Context Menu (for ZiT)
- When using GCT Wizard on a Search Result, the address/value from that result will be loaded into the Wizard automatically (for Bully)
- If the Search Comparison Value text box is empty but also disabled, the Search will still continue (for Bully)
- When using the GCT Wizard from a context menu, it will load the code that is currently selected in the GCT Code tab. This makes it easier to "build" a code one line at a time by leaving it selected when you leave the GCT Code tab. To make the wizard load a New Code, make sure no code is selected
test build r108 (http://www.mediafire.com/?yg8rngk4js8ryy6)
- Fixed the "no multi-poke data available" bug (introduced some time around Serial Poke); right-clicking on search results sometimes wouldn't load the addresses into the multi-poke address history
- When search result view mode is float, the difference column is now calculated correctly
test build r109 (http://www.mediafire.com/?wd224m9nobo7c3v)
I have an awesome new feature to introduce. The disassembly tab now supports a call stack! When the game is paused at a breakpoint, go to the disassembly tab and either double-click the Call Stack list box, or right-click and then click "Load". You must do this manually because the process is a little slow.
It will automatically parse the stack for the LR save word from each stack frame, and then fill the list box with the current instruction address and every bl that lead up to the current instruction. You can double-click on any address in that list box and the disassembler will automatically jump there.
A long time ago, I wrote a guide about walking the stack. http://wiird.l0nk.org/forum/index.php/topic,5080 It explained how to follow function calls so that you can find the best place to patch the ASM. The new call stack list box has reduced this guide to "double-click each one of those addresses and look for something interesting"
---
- Added Nuke's SetLatencyTimer call. Everything is much snappier now. Auto-Update MemView goes 15 dps! Breakpoints hit faster.
- Disassembler uses random temporary file name instead of diss.bin; prevents problems where diss.bin gets locked somehow (this should help giantpune)
- Added Disassembler Context Menu items that jump to function start and end
- When left clicking the Step Out button , it will attempt to guess whether leaf or stack frame is the appropriate method of stepping out. In rare circumstances, it can be fooled by conditional blr's (beqlr/bnelr/etc, but not plain old blr), however all it does is go an extra step out so there's no real harm. You can still manually choose leaf, stack frame, or walk to blr from the Step Out context menu. Walk to blr is still useful sometimes, like when using the Log Steps checkbox. It will never mess up, but it is the slowest.
awesome, thats very handy
ta dcx
very handy indeed. this version has fixed the crash i was getting with the last one about the diss.bin :) . however, i notice the callstack in "forgotten" by simply changing tabs. even if you dont click on anything in any other tab. i went back to the breakpoint tab to look at something and when i came back to look at teh call stack, he has been wiped out again. anyways, im sure its a pretty easy fix to clear it up. and a great addition to the program.
yea if you click on the callstack box after it loaded it will also disappear :(
It's been a long time coming, but now there's a new "official" build.
http://geckowii.googlecode.com/files/Gecko dNet 0.63.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.63.zip)
- Call Stack is not cleared anymore when Disassembly tab gains focus
- Address text box context menu now supports adding or subtracting a hex offset
- Memory Viewer context menu also supports adding or subtracting a hex offset
- Source code is now hosted at Google Code! http://code.google.com/p/geckowii/source/browse/
Awesome. Pure awesome.
Thanks a ton, dcx2!
;D Who rocks?
dcx2 dose. 8)
Thank Link, too...he set up the Google Code account. Then it took me about two hours to figure out how to get the code there and organized...lol, you can see it's at r10 already...
I plan on releasing a tutorial that explains how to run the app from source, in debug mode, with pics. Then, you can even edit the source while the app is running, drag the current execution pointer around during a breakpoint, etc. It's quite bad-ass.
Here are the major changes since the last official release. We really, really need documentation that has pictures and proper explanations of the features...
Changes for 0.62 are here http://wiird.l0nk.org/forum/index.php/topic,4886.msg53436.html#msg53436 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg53436.html#msg53436)
---
Search:
- compressed search histories with multi-level undo and save/load
- Search comparison groups for multiple simultaneous search conditions
- Multi-Poke uses the Poke address textbox history
- Serial Poke (pokes the multi-poke list one at a time)
Memory Viewer:
- Single/float and "auto" memory viewer display modes
- search can look for strings of 256 characters or bytes
- grid context menu improvements; font size, jump to offset
Breakpoints:
- Breakpoint step logging with annotations and indenting
- Show Mem button now has its own Context Menu, that is shared with the Step buttons too
- Improved Step Out (left click "guesses" the right caller) with its own context menu; stack frame, leaf, Walk to blr (safest)
Disassembly:
- call stack
- assembler history
- context menu improvements; Set SRR0, Copy Function, Goto Function Start/End
- search with regular expressions
General:
- quietly attempts to reconnect and continue e.g. searching or breakpoints before requiring user intervention
- faster response thanks to Nuke's SetLatencyTimer suggestion
- "Bug fixes"
If said documentation comes to be, I can put it on GeckoCodes.
What version of Visual Studio do you use dcx?
Visual Studio Express. I think it's 2008.
To connect to google code, I use TortoiseSVN.
SVN updated; small bug in the Memory Viewer Search code that would only return correct results for the first dump; if it had to dump more than once it would be off.
There are other features I plan on adding...I want the MemView Search to be cancel-able, and I will probably convert disasm Search to cancel-able instead of repeated prompts.
Once that's all in, I'll release another build. Until then, if you're just dying to use MemView Search, build from the sources.
SVN updated. Test build r114 released. http://geckowii.googlecode.com/files/Gecko dNet r114.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%20r114.zip)
In addition to the Memory Viewer Search bug fix from the previous update...
- Memory Viewer searches can be canceled
- Disassembly searches can be canceled
- If either search reaches the end of memory before being canceled, a message box will notify the user
test build r115 (http://geckowii.googlecode.com/files/Gecko%20dNet%20r115.zip)
- MemView address is centered and selected when entering the MemView tab. This prevents some situations where the MemView address could be different from what was actually displayed in the grid and range dropdown. This could sometimes cause crashes with certain addresses when the scrollbar was clicked
- Extra protection against scrollbar/MemView address disagreements. However, it's still possible (but much harder) to break it...you must switch to MEM2, scroll past 91800000, then manually edit the 9 to be an 8, and then click on the scroll bar.
- Changing the MemView Address Range dropdown will put you in a proportionally appropriate area in the new memory range, instead of just defaulting to the lowest value. ie if you were looking at the end of mem2 and you change to mem1, you'll see the end of mem1
- The exceptions log file is a unique name every time, derived from time and date, stored in a "Logs" subfolder relative to the exe
- Sorting and history compression no longer write to the log file; less chance to cause a crash there
- Exception handling is now wrapped around the log file's constructor, in case we still can't touch the unique file
nice :cool:
is the x in your name a multiplier?
Nope, just a letter. I try to keep my online life and offline life as separate as possible, which necessitated a somewhat random username. Look at it as "xkcd, with a 2 instead of a k, backwards and rearranged". xkcd is in fact my favorite web comic.
A Venn Diagram of my online/offline lives almost make a circle.
Example: The x in /my/ name is part of the hex denotation, '0x' making '0x57' actually mean 87. 1987 was the year I was born.
Sorry to ask since the info is probably in the thread somewhere; but did you add the value mask for searching?
Yeah, when you posted your 23rd birthday, I figured the 0x57 was the year you were born. Clever...very hackerish. I approve. ^_^
I have not yet added masking for searches. I've been considering it, though. However, I would like to devote some more time to the mono implementation; last week, they released mono 2.8, so one hopes that there are all-around improvements. And giantpune has some good suggestions for generalizing the Linux interface with the USB Gecko.
And I'd also like to finish some more documentation, so people know what features exist.
And I'd also like to do some video tutorials that show off some features. Like a C0 debugging tutorial so people can see that you can in fact recover from a crash.
And I'd also like to solve world hunger, bring peace to the Middle East, create nuclear fusion on earth that generates more energy than is put in...
Quote from: dcx2 on October 13, 2010, 07:10:55 PM
And I'd also like to solve world hunger, bring peace to the Middle East, create nuclear fusion on earth that generates more energy than is put in...
I doubt the Mono release will help you much on these plans :P
Quote from: dcx2 on October 13, 2010, 07:10:55 PM
And I'd also like to do some video tutorials that show off some features. Like a C0 debugging tutorial so people can see that you can in fact recover from a crash.
Awesome, but I doubt that anybody will do it. It´s really easy with Camtasia Studio 7, because you can record your screen with good quality. Then, add some annotations on youtube or with windows movie maker 2.6. These programs are all for free, so be free to create something epic (@every "good" hacker) ! :D
If you guys want a TuT for anything I can manage, it´ll be glad to make a video ;)
Not for you "old hackers" to learn something new (!), mostly for beginners to learn a bit more, which I needed to learn hard with a bit help :P
Camtasia is not free ("30-day free trial!"). However, CamStudio is an open-source equivalent.
Also, the principals behind C0 debugging apply to C2 debugging as well. It's just that a C0 example would be easier to demonstrate, because a C2 example depends on finding an address to hook.
Quote from: dcx2 on October 13, 2010, 09:28:03 PM
Camtasia is not free ("30-day free trial!").
damn, I forgot to say that, BUT you can use it freely for 30 days... :)
So it´s enough for some projects...
Not sure if I should post this here or in a different thread, but here's a couple of patches:
http://www.mediafire.com/file/5zk69ayepebcnsa/gdn_patches.tar.gz
All of them deal with cross-platform/Mono stuff. They are Linux patch files, but they should be legible enough to figure out just by opening them in a text editor (if you make the changes on Windows).
Also, thanks for making the source available on SVN. :)
EDIT: Ignore the patch for libftdi.cs - was a misunderstanding on my part.
Can´t you just upload the exe?
Why should people patch it for themself, pointless.
Thx :p
That patch is for mono users (i.e. Linux), so Windows users don't need it, and mono users will typically be compiling from source.
re-post since r115 fell off the last page and might be harder to find...
test build r115 (http://geckowii.googlecode.com/files/Gecko%20dNet%20r115.zip)
- MemView address is centered and selected when entering the MemView tab. This prevents some situations where the MemView address could be different from what was actually displayed in the grid and range dropdown. This could sometimes cause crashes with certain addresses when the scrollbar was clicked
- Extra protection against scrollbar/MemView address disagreements. However, it's still possible (but much harder) to break it...you must switch to MEM2, scroll past 91800000, then manually edit the 9 to be an 8, and then click on the scroll bar.
- Changing the MemView Address Range dropdown will put you in a proportionally appropriate area in the new memory range, instead of just defaulting to the lowest value. ie if you were looking at the end of mem2 and you change to mem1, you'll see the end of mem1
- The exceptions log file is a unique name every time, derived from time and date, stored in a "Logs" subfolder relative to the exe
- Sorting and history compression no longer write to the log file; less chance to cause a crash there
- Exception handling is now wrapped around the log file's constructor, in case we still can't touch the unique file
Gecko.NET 0.64 is live!
http://geckowii.googlecode.com/files/Gecko dNet 0.64.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.zip)
-Memory Viewer searches can be canceled
-Disassembly searches can be canceled
-Fixed load search button
-Memory Viewer bug fixes
-Search bug fixes (thanks Patedj!)
Exception log - if Gecko.NET crashes, please go to the Logs folder and send me a PM (http://wiird.l0nk.org/forum/index.php?action=pm;sa=send;u=7180) with the exception info so I can help you
Skip Unaligned Data Breakpoint checkbox on the About tab - Data breakpoints (with Exact checkbox disabled!) are double-word aligned, meaning they can hit on a memory access of any 8 bytes. So you could set a breakpoint on 80123444, but if the processor writes to 80123440 your breakpoint will hit, even though it's the wrong address. To help avoid confusion, this setting will skip any breakpoints that aren't word-aligned with the address. If you don't know what any of this means, just trust me and leave it checked, it will protect you from fake breakpoints
Memory Viewer and Disassembly dump redirection - If you make a complete dump of MEM1 or MEM2, you can choose to read from those dumps instead of the USB Gecko. Incredibly useful for porting codes
---
Changes for 0.63 can be found here http://wiird.l0nk.org/forum/index.php/topic,4886.msg58943.html#msg58943 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg58943.html#msg58943)
Gecko.NET 0.64.1
http://geckowii.googlecode.com/files/Gecko dNet 0.64.1.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.1.zip)
-game version fix (reads game version from 80000007)
-bug fixes (memview poke divide by zero, empty Copy Function)
-widen search result address column so you can see sort tick
-memview search shows where it's dumping from
TIP: When using dump redirection without attaching to the USB Gecko, it helps to unplug the USB Gecko from the PC's USB port. If the USB is attached, it will repeatedly try and time out. If no USB is attached, it instantly times out. If it throws up error messages, you can repeatedly say no and they will eventually stop.
Gecko.NET 0.64.2
http://geckowii.googlecode.com/files/Gecko dNet 0.64.2.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.2.zip)
can save search result histories to other folders
search result history save file dialog initialized to gamename, and ensures unique file names
search result history extension is now .srh instead of .zip to prevent confusion; you can just rename an existing .zip (NOT a DumpHistory, a zip created by the Save Search before I changed the extension) to .srh or you can even still load .zip by changing file type to *.*
if you load search on a .zip file in the DumpHistory folder, it will reconstruct the search history using that zip and all the ones before it. This can be used to re-load an old search history even if it wasn't saved
Gecko.NET 0.64.3
http://geckowii.googlecode.com/files/Gecko dNet 0.64.3.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.3.zip)
Altered a lot of USB Gecko code; everything seems faster now. auto-update memory viewer is 45-60 dumps per second (previously 15), Breakpoints can hit at 50 hits per second (previously 6), steps can be logged at 15 steps per second (previously 3); breakpoints also hit more reliably. This is a major, major change, and I really need people to confirm that this is still stable.
Other minor changes...
-disassembler scrollbar works correctly now
-things that set disassembler address (hitting a breakpoint, context menu, etc) now show the 10 instructions before it
-BP tab disassembler can now scroll back 10 instructions
-If slow mo is active, and you press Pause/Next Frame, it will actually pause now
i always got 60dps... ._.
Whoa! That's one hell of an improvement! I'll look forward to that next time I hack for sure!! Thanks for everything you put into this project man!!! =D
Quote from: hetoan2 on March 27, 2011, 12:58:09 AM
i always got 60dps... ._.
What? No way...
Sometimes I could get faster dps, but only if the game was paused or at a breakpoint. If it was actually running, it was usually 15. I think I saw 20 for one game.
Either way, everything should be more reliable now. If you had ever tried to set a breakpoint condition that was skipped a lot, like hundreds of times, I always found it unreliable (even with WiiRDGUI). Or if you tried to Step Until while using Step Log, it would sometimes stop stepping. All that is fixed now; I set a condition that was always skipped and I got over 50,000 skips without problems.
Quote from: James0x57 on March 27, 2011, 02:15:47 AM
Whoa! That's one hell of an improvement! I'll look forward to that next time I hack for sure!! Thanks for everything you put into this project man!!! =D
Quote from: hetoan2 on March 27, 2011, 12:58:09 AM
i always got 60dps... ._.
What? No way...
I will screen cap it if you want. I always play games at full speed while using live memory viewer. @_@ i thought this was normal. These are games like black ops too. Don't know if that factors into it.
Gecko.NET 0.64.4
http://geckowii.googlecode.com/files/Gecko dNet 0.64.4.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.4.zip)
-Search Dump Verification; This will double check that the dump has transferred from the USB Gecko to the PC correctly. No more vanishing search results! ;D
-Dump blocks in 1 MB chunks, like WiiRDGUI. This reduces the risk of encountering multiple errors in a single block
-Search dump label now gives more info about searching process
- Improved disassembler's assembly history textbox
---
The dump verification is at a point now where others can use it safely. If this doesn't give anyone grief, I'll probably rev it up to 0.65, because this is a pretty big deal.
Gecko.NET 0.64.5
http://geckowii.googlecode.com/files/Gecko dNet 0.64.5.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.5.zip)
-fixed current working directory bug which could cause problems finding vdappc
-tools -> dump is now a safedump
-disable Search tab's Memory Range and Data Type dropdowns during searches
-ctrl SHIFT click in Memory Viewer to add that cell to the Memory Viewer Hex search; this is helpful when you are porting codes from one dump to another and you need to create the list of "unique bytes" to search for
-memview search is now multiline so you can see the entire search string
EDIT: it's not ctrl click, it's shift click.
Gecko.NET 0.64.6
http://geckowii.googlecode.com/files/Gecko dNet 0.64.6.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.6.zip)
-Fixed bug which caused a canceled search to freeze during verification
-Added Copy All Frames to disassembly context menu
Copy All Frames does the following:
It parses the call stack. It then copies all the functions in the call stack, in the order they are called. It indents each function. At the current instruction, it will place a copy of the registers. If the current instruction accesses memory, it will show the effective address in []'s, as well as a peek at the value (just like the Step Log).
All of this text goes into the clipboard. I suggest pasting it into Notepad and make sure wordwrap is off. It will be very large.
---
If you experience any bugs while using Gecko.NET, pleasepleaseplease click on the Bug Report link in my sig and let me know.
Quote from: dcx2 on March 30, 2011, 03:43:24 PM
Gecko.NET 0.64.4
http://geckowii.googlecode.com/files/Gecko dNet 0.64.4.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.4.zip)
-Search Dump Verification; This will double check that the dump has transferred from the USB Gecko to the PC correctly. No more vanishing search results! ;D
-Dump blocks in 1 MB chunks, like WiiRDGUI. This reduces the risk of encountering multiple errors in a single block
-Search dump label now gives more info about searching process
- Improved disassembler's assembly history textbox
---
The dump verification is at a point now where others can use it safely. If this doesn't give anyone grief, I'll probably rev it up to 0.65, because this is a pretty big deal.
as much as I am not on this forum.. I too also have rather fast DPS with Gecko.NET when im using it... usually on GUI I'd get 20 DPS but on .NET I get 48DPS or higher.. if GUI is running at 30 DPS then .NET gets around 70 DPS.. Often times I forget im running it...
I wonder if the memory dump speed is affected by hook type. Are your fast games using OSSleepThread?
i would assume the osthreadsleep hook would result in the codehandler being run more often then the other hooks. most of them are targeting a function that is only called in 1 thread ( like video and controller functions ). but osthreadsleep is likely to be called from every thread running in the game. it potentially will run the code handler multiple times for every frame of the game.
speaking about threads and whatnot, does the codehandler do anything to prevent switching to another thread while it is running? say you are using a hook that targets the padscan function. the codehandler would only be working on that thread. and what if the game tries to change to a different thread and do some work while the codehandler is dumping memory? does that mean there is potential for the game to modify RAM while you are digging around in there?
I think dumping memory works differently from handling the codes. I think the "code handler" is actually split into two parts - the "user-mode" code handler, that reads the cheat codes from memory and acts upon them; and a "kernel-mode" interrupt handler which is called when dumping memory, setting breakpoints, stepping, etc.
If you step through the code while doing a dump, you will see that as soon as you send the readmem command, the game will instantly freeze, even before you read the ack. So there shouldn't be anything modifying the RAM while doing a single dump.
A long time ago, during block searches there was a problem where the game would advance a few frames between each block. To deal with this, before doing a dump, the game is now paused. After the dump, the game is unpaused if it was running before the dump.
While testing search verification, I did MEM2 unknown-equal dumps repeatedly. I probably transferred about 2 GB of data over the USB Gecko, and the data never changed while it was paused.
Gecko.NET 0.64.7
http://geckowii.googlecode.com/files/Gecko dNet 0.64.7.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.7.zip)
Pointer Search Edition!
Dr. Pepper's pointer search v3 is now bundled with Gecko.NET. It has its own tab. It's a little rough around the edges, but it should be useful. Please let me know how it works, if you have any suggestions to make it easier to use, etc.
When you find an address, put it in the textbox next to the dump on the Pointer tab. Then press "dump 80" or "dump both". It will automatically suggest filenames for you and prompt you for a location to save the dumps to. Once dumped, the appropriate checkboxes are enabled.
Get the next address, put into the next textbox, press the dump button again, save the files. Do this a third time if you want.
To use a previously existing dump, just click the checkbox. An open file dialog will prompt you to locate the dump to load.
To see what dump is loaded for a given checkbox, right-click the checkbox.
Click Search to run Dr. Pepper's app. Make sure you have at least two dump80's.
It will copy the dumps to where the pointer search expects them to be, so make sure you have enough free space. A dump80 and dump90 together take up about 75 MB, if doing three of them, the copies will mean there's six total dumps, about 450 MB total.
---
Other goodies...
-rearranged some tabs; tools tab can now specify the path for integrated tools below
-integrated ASMWiiRD to GCT Code Context Menu; copies the C2 code into ASMWiiRD (launching if necessary) and converts it to ASM automatically
-integrated PyiiASMH to GCT Code Context Menu; copies the ASM code into the clipboard, then launches PyiiASMH if necessary. You must manually paste the ASM code into the right textbox.
-Memory Viewer Search type is now persistent between runs
-Fixed bug with assembler history textbox
-Fixed bug with screenshot capture (another "current directory" bug)
-If Paused while Auto-Preview on Screenshot tab, the game will advance one frame between Previews.
Thanks dude, haven't been around for a while but gonna get back into things I think starting with this new version!
Quote from: dcx2 on April 07, 2011, 06:43:52 AM
It will copy the dumps to where the pointer search expects them to be, so make sure you have enough free space. A dump80 and dump90 together take up about 75 MB, if doing three of them, the copies will mean there's six total dumps, about 450 MB total.
so you are saying that this is copying the entire contents of mem1, then mem2, and then mem1 + mem2 all across the usb gecko? would it not be faster to dump mem1, then men2, and then just copy those dumps to make the mem1 + mem2 version? or am i misunderstanding this?
I think you're misunderstanding.
You collect dumps at any time. You can even use previously collected dumps. These dumps can be named whatever you want, and can go in any folder. MEM1 and MEM2 only come across the USB Gecko once per pointer.
However, Dr. Pepper's Pointer Search requires that the dumps have specific names (dump_80.bin, dump_90.bin), and that they are located in specific folders ([app]/data1, [app]/data2, [app]/data3)
When you press the "Search" button on the Pointer tab, Gecko.NET will delete any old dumps in the data1/2/3 folders, and then it will copy the checkmarked any-name, any-location dumps to the specific data1/2/3 folders with the specific dump_80 or dump_90 file names, where the Pointer Search expects them to be, before calling the app.
The "Search" button does not initiate ANY transfers from the USB Gecko. So you can go about your business while the Pointer Search is running in the background.
Gecko.NET 0.64.8
http://geckowii.googlecode.com/files/Gecko dNet 0.64.8.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.8.zip)
Did you ever send an ASM code to the game via the GCT tab, and then want to turn it off? Even if you "Disable Codes", the code is still in effect. This is because nothing has un-patched your ASM code. Well, that problem is now solved! I give you...GCT Code Undo!
There are new checkboxes on the GCT tab - "Undo After Disable" and "Undo Before Sending". If they are checked, and you add ##address original_value to your GCT code, it will be ignored when sending codes, however when undoing codes it will poke address with original_value, so that ASM hacks are turned off
For instance, I have a Wii Play code
[no limit on bullets]
##8025F874 408100A0
0425F874 60000000
---
Pause While Sending will use an XBP on the code handler, no matter what BPNext is set to. Previously, if BPNext was not enabled, Pause While Sending would not prevent the crash it was designed to stop.
Combined with proper use of GCT Code Undo, there should be no more crashes when sending new codes to the game.
---
Clears receive buffer efficiently if there are leftover bytes, so that they can't interfere with the next command. This problem is actually more common than you would think...if you were having any problems before, this change might solve them.
CyclePort when Disconnect pressed. You can now press "Disconnect" and it will act like the USB Gecko was unplugged and plugged back in.
Properly disconnect the USB Gecko when there is no Wii running. This means no more error messages when using Dump Mode without a Wii running!
Auto capture screenshots. Works just like auto-preview; if paused, it will advance one frame between shots, otherwise it advances many frames.
Gecko.NET 0.64.9
http://geckowii.googlecode.com/files/Gecko dNet 0.64.9.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.9.zip)
-Automatically patch the code handler to remove the rx and tx bugs. You no longer have to apply the C2 codes to fix those bugs, it's all done for you. This supports both Gecko OS 1.9.3.1 code handler (most common), as well as the more recent 1.9.3.2 handler.
-Changed SetLatencyTimer to 1, which speeds up some transfers
Gecko.NET 0.65
http://geckowii.googlecode.com/files/Gecko dNet 0.65.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.zip)
Specific Changes since 0.64.9:
-Increased Watch List speed. If you load lots of addresses, it may slow the game down. Resize the window so that fewer addresses are visible and it will speed up.
-Added Breakpoint Condition: Value of Address. Normally Breakpoint Conditions only test registers (i.e. only hit breakpoint if r0 != 0). In the Condition Register dropdown at the bottom, after the float regs, is now "BPAdr". When you hit "add", it will take the current Breakpoint address and add it as a condition (i.e. [80001234] == 3).
Since you can copy and paste breakpoint conditions in and out of the condition listbox, if you want to test many arbitrary addresses it would be easier to copy one BPAdr condition to Notepad (to get the format), copy and paste many duplicates, change the addresses and values, and then copy back to the condition listbox.
---
For changes since 0.64, follow the thread along from here http://wiird.l0nk.org/forum/index.php/topic,4886.msg67325.html#msg67325 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg67325.html#msg67325)
Is this of any use if we don't own a gecko USB? I have found out that I can ram dump?
WAs this program coded in VB or C# cause at the begginning it looked like it was then, it switched to C? :S
WiiRD Console was built by Link in Deplhi, I believe. WiiRDGUI was a front-end to the console built by kenobi, I think it was written in C++. Link "ported" both to C#, and then I proceeded to jam it full of extra features.
Gecko.NET 0.65.1
http://geckowii.googlecode.com/files/Gecko dNet 0.65.1.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.1.zip)
automatically update MemView when switching to that tab
fixed GetRegisters bug that would sometimes cause problems when hitting breakpoints or stepping
no need to reconnect twice to enable all the controls again
failure to shut down watch list thread was occasionally causing a zombie process that would require End Task in Task Manager. if the watch list fails to close, it will ask you to close the app again.
Gecko.NET 0.65.2
http://geckowii.googlecode.com/files/Gecko dNet 0.65.2.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.2.zip)
exception bugfix (should improve stability)
check GCT code undo for valid address before poking
include indexed load/stores with Step Log
can disable the debugger rx/tx patch on about tab. If this was enabled and then becomes disabled, it could cause the current game to crash.
fixed PyiiASMH utility link
pointer checkboxes/button will complain instead of crashing if PointerSearch cannot be found
canceled searches complete faster
Gecko.NET 0.65.3
http://geckowii.googlecode.com/files/Gecko dNet 0.65.3.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.3.zip)
Fixed RXTX patch disable; disabling actually didn't work in the last version, even though the about tab was unchecked
Unhook RXTX patch; if the about tab is not checked and you click "Disable" on the GCT tab it will unhook the patches
Gecko.NET 0.65.4
http://geckowii.googlecode.com/files/Gecko dNet 0.65.4.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.4.zip)
hold shift to prevent automatically connecting on startup
F2 XOR calculator on Tools tab, copies the whole F2 line to the clipboard when you click XOR
rooted the codes path (prevents "moving codes folder" if you change log/dump directories)
no more ghost gct code when an Add GCT Code is canceled
active codelines counter on GCT tab
memview context menu - added tools tab start dump address and tools tab end dump address shortcuts; end will auto-switch to Tools tab
disasm context menu - added F2 XOR address and Y shortcuts. Y will automatically calculate the right Y value to count all the bytes from the F2 XOR address to the selected address.
disasm context menu - add to gct code, instead of creating new code
right-click on disasm instruction selects that line
Gecko.NET 0.65.5
http://geckowii.googlecode.com/files/Gecko dNet 0.65.5.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.5.zip)
added support for extended codes. check the checkbox on the about tab. then on GCT tab, click on a code until the background of the checkbox is red, and it will be sent to the alternate code list. must apply code extender via SD patch; or pause-start, apply codes, and then EXBP before the hook.
fixed ghost add gct code for memview context menu
fixed memview context menu upload bug
more exception bugfixes
---
Apply this code extender via SD cheats to enable the extended codes feature. Major props to Y.S. for figuring this out
F6000001 80008180
54030034 48000008
D2000000 00000007
54030034 3D8000D0
618CC0DE 91830000
91830004 3980FFFF
91830008 9183000C
38630008 3D808000
906C1848 38637FF8
60000000 00000000
E0000000 80008000
Apply this code via send cheats to activate the extended codes feature
26001848 81800000
24001848 80000000
64000000 00000000
E0000000 80008000
Gecko.NET 0.65.7
-link removed- .7 was kinda buggy too, use .8 instead
Extended Code support is now almost fully automatic; no more extended codes checkbox on about tab, no more redcheckbox on GCT tab. If the extended code list exists, all codes will be sent there and the Extended Codes Activator (the 64 code-type return) will automatically be added to the original code list. The only thing you have to do now is have a gct with the Extended Codes Allocator. Or...
You can now pause-start a game and apply the Extended Codes Allocator and then hit run. This way you don't need a gct file for each game you want to hack.
The code line limit is displayed on the GCT tab. So you now know how many codes you can send.
On the GCT tab, highlight the first word of a cheat (e.g. C2001234 or 04005678 etc), and the following shortcuts will treat it as an address with ba = 80000000:
- ctrl+u will automatically add a GCT Code Undo line by peeking at the address and using the current value (VERY useful, but make sure you do this before activating the cheat! I load a new game without cheats and then go through and add the Undo for each code)
- ctrl+d will go to that address in disassembler
- ctrl+m will go to that address in memory viewer
The disassembly context menu's Copy now copies only one line into the clipboard. Copy Visible was added, and it does what Copy used to do, which the visible disassembly into the clipboard
smaller debugger patches that aren't C2 codes anymore. note: patches only work for 1.9.3.1 for now, I have to port them to .2 manually
additional debugger patches - execute codes after send cheats, flush/invalidate C2 branches. These make Pause While Sending obsolete. C2 codes will always work now without problems. When using GCT Code Undo, you can enable and disable any C2 codes and it will not crash.
EDIT: oh yeah, general little bugfixes
0.65.6 had a pretty bad bug, please get .7
Gecko.NET 0.65.8
http://geckowii.googlecode.com/files/Gecko dNet 0.65.8.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.65.8.zip)
.7 had a lot of little weird bugs. They should be fixed now. I think one of the bugs means it would crash the Wii if you didn't use SD cheats. It would also crash on any code handler that wasn't 1.9.3.1. It would get stuck in a dump-loop on 1.9.3.2. It would crash 1.9.3.1 without the debugger patches.
That is all fixed now. I tested it with and without SD cheats, with and without pause start, with and without extended code list, with GC games, and with VC games. This was all done on 1.9.3.1 and 1.9.3.2 code handlers. I also tested Gecko OS Mod, which is an unsupported code handler, but only with GC games.
0.65.8 now supports debugger patches for the 1.9.3.2 code handler. You cannot disable the debugger patches anymore. However, code handlers that can't be patched (e.g. Gecko OS Mod) shouldn't cause crashing anymore.
Also, if playing a multi-disc GC game, the second disc will now show up as Disc 2 in the title menu.
oh awesome. I was getting ready to report the crashing bug. Hopefully it won't crash for no reason anymore.
please refrain from posting comments in the release thread.
There´s a discussion thread for anything related to geckodotnet:
http://wiird.l0nk.org/forum/index.php/topic,4954.0.html
Gecko.NET 0.66.0
-removed- use 0.66.1 instead
auto-save GCT checkbox on about tab, saves GCT list every time it is modified
compress and store backups of every code list saved in ./codes/codeBackup.zip so that you never lose codes
disasm remembers address now
fixed some exceptions
Won't prompt for save when closing if the codes were already saved
---
added Tracer support to Tools tab. Tracer is a NES/SNES disassembler. You can use it when hacking VC games. I can't distribute the app because I don't know what license it has, but you can find it easily if you google SNES tracer. Once you have Tracer downloaded, put it in the same folder, then go to Tools tab, and Browse to it.
To use Tracer, first go to Tools tab and put a filename into Memory Dumping. If the file already exists, Tracer will use it without dumping it again. If you change the Dump addresses, you will need to Dump before you run Tracer. You can use the MemView Context Menu Dump Start/End shortcuts to help you make dumps for Tracer.
Review the Tracer documentation to become familiar with the command-line switches for it. Disassembling SNES code is painful, because it can be in 8-bit or 16-bit mode (the -a switch). When you press the Tracer button, it will prompt you for what command-line switches you want to pass to it. If the disassembled output makes no sense, try some different switches. Remember that the file to be disassembled will be selected using the Memory Dumping filename field; if it already exists, it will be used as-is, so make sure you're using a recent dump.
SNES also uses variable-length instructions. Some are 1 byte, others are 2, 3, or even 4 bytes. So if the ASM doesn't make sense, you may need to move a byte or two forward or backward to line up with the real ASM. This is in addition to any switches Tracer might need.
You can also use pipes and output redirection in the Tracer command line. However, the instruction offsets from Tracer will probably be wrong, and you will have no way to know what Wii address a SNES ASM instruction lives at. So I added a small app named RiiTracer. You can pipe the output of Tracer into RiiTracer and pass in the dump's start address, and RiiTracer will reformat Tracer's output to have Wii memory addresses. You can also use output redirection to write the results to a text file.
For example, give the following line to Tracer, and it will parse the contents of the file and reformat the output to start at Wii address 90001234, and then write the output to foo.txt.
-a | RiiTracer 90001234 > foo.txt
If you want to patch the SNES ASM, you will need to hand-craft it using a SNES reference.
Here's a snippet of RiiTracer'd output from Tracer showing a SNES function from Mega Man X.
[spoiler]901C1356:804D: 08 PHP
901C1357:804E: 0B PHD
901C1358:804F: F4 00 00 PEA $0000
901C135B:8052: 2B PLD
901C135C:8053: E2 10 SEP #$10
901C135E:8055: 86 2C STX $2C
901C1360:8057: A0 00 LDY #$00
901C1362:8059: BB TYX
901C1363:805A: E4 2C CPX $2C
901C1365:805C: B0 1C BCS $807A
901C1367:805E: B9 00 00 LDA $0000,Y
901C136A:8061: D5 00 CMP $00,X
901C136C:8063: B0 09 BCS $806E
901C136E:8065: 48 PHA
901C136F:8066: B5 00 LDA $00,X
901C1371:8068: 99 00 00 STA $0000,Y
901C1374:806B: 68 PLA
901C1375:806C: 95 00 STA $00,X
901C1377:806E: E8 INX
901C1378:806F: E8 INX
901C1379:8070: E4 2C CPX $2C
901C137B:8072: F0 EA BEQ $805E
901C137D:8074: 90 E8 BCC $805E
901C137F:8076: C8 INY
901C1380:8077: C8 INY
901C1381:8078: 80 DF BRA $8059
901C1383:807A: 2B PLD
901C1384:807B: 28 PLP
901C1385:807C: 6B RTL
[/spoiler]
Sweet that be a nice add in :)
does that trace app alow u to Convert Op to hex .. iv been messing around with some X86 pc games and that snes looks about as fun as that to hack for ASM code lol :P
Tracer is only a disassembler. You will have to hand-code assembly by looking up op codes in a SNES reference.
SNES ASM is worse than x86. SNES CPU has two modes, 8-bit and 16-bit accumulator. So the same binary code can be interpreted to mean two totally different things.
is that not the same as the DS .. Sware it also has 16 and 32bit .. Arm another pain in the ass ..
Whats Snes use anyways ..
Gecko.NET 0.66.1 (Don't use 0.66.0)
http://geckowii.googlecode.com/files/Gecko dNet 0.66.1.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.66.1.zip)
Fixed GCT save bug. New codes could be created, but existing codes could not be modified
When connecting, the Gecko OS breakpoint handler will be automatically installed if it has not been installed already. This will allow Gecko.NET to catch game crashes without having to set a breakpoint first.
Gecko.NET 0.66.2
-removed-
disable mem2 when in GameCube mode
MemView now shows ASCII for selected cell below the float value
fix ASCII to hex in context menus
memview selected address jumping when changing tabs
textbox that doesn't get 0-filled to add GCT code line
cheats sent to status bar
16-/8-bit poke reads the right value
16-/8-bit multi poke works correctly
multi-poke using value from new or old col. Make the Poke Value NEW or OLD and it will read the value from the corresponding dump. Also works for single poke
all multi-poke improvements work for serial poke too
fixed initialization bugs that might cause zombie proc or locked up the USB Gecko
driver version detection and update link in Tools tab if driver is out-dated
Gecko.NET 0.66.3
-removed- context menu memview shortcut bug
The zip file for 0.66.2 contained the 0.66.1 exe file. :( 0.66.3 has the real update.
Gecko.NET 0.66.4
http://geckowii.googlecode.com/files/Gecko dNet 0.66.4.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.66.4.zip)
- fixed context menu memview shortcuts
- fixed up/down/pageup/pagedown for memviewgrid
- fixed memview scrollbar detection of the bottom
Gecko.NET 0.66.5
http://geckowii.googlecode.com/files/Gecko dNet 0.66.5.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.66.5.zip)
- fixed memview context menu add offset
Gecko.NET 0.66.6
http://geckowii.googlecode.com/files/Gecko dNet 0.66.6.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.66.6.zip)
-memview update button fix
-connect button fix
-improved classic "next frame" (i.e. BPNext unchecked) so it always steps forward by only one frame. This makes BPNext mostly obsolete now
-GCT tab Active Lines properly calculates size of 1932 code handler code list (smaller than 1931, changes in size depending on how many C2 codes were sent)
-another debugger patch - invalidate and flush all bytes from exireceivebuffer (both 1931 and 1932), this fixes problems with sending some C0 codes which would crash the game.
A little bit of background on the new debugger patch. One problem with C2 codes is that their branches weren't written immediately after they were uploaded. So I made a debugger patch that runs the code handler after uploading codes, so that the C2 code branches are always correct. This ended up creating a new problem - when you send C0 codes, the code handler executes them immediately now, but the data/instruction cache were not properly flushed so the game would crash when it tried to execute with the stale cache. This wasn't a problem without the C2 debugger patch, because the game would execute one frame before executing the code handler, which would naturally force the cache to be flushed.
Funny how a debugger patch to fix one problem ended up creating another. Either way, it's all good now, C0 codes and C2 codes won't cause crashing.
Gecko.NET 0.66.7
http://geckowii.googlecode.com/files/Gecko dNet 0.66.7.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.66.7.zip)
- Fixed MEM2 protection so that you can see it while debugging channels
- MemView auto-update only updates when looking at MemView tab
- MemView tab is rearranged a bit to make room...
- MemView Selected Address will now go to that address if you press enter in that textbox
- MemView Selected Address history can be actively scrolled through using up/down arrow keys
- Double click an addresstextbox to add its contents to the history automatically
- addresstextbox cut/copy/paste stuff works correctly now
- Data textboxes can now take up to 10 digits for doing conversions, but remember that when its value gets used it must be an 8 (or 4 or 2) digit hex value.
- Loading GCT list the first time isn't slow anymore
- exisendbyteAA protection (I think this should stop some connection problems like e.g. MH3 loading screen freeze)
- Renamed Search Groups to be Multi-Search instead
- Search result context menu now makes correct New GCT Codes for 8- and 16-bit
---
- Patch debugger to support extra PowerPC exceptions! The Program and ISI exceptions will now be caught by the code handler. This should allow you to recover from more crashes. What are these?
ISI exception happens when an instruction can't be fetched. Let's say something terrible happens and somehow the game tries to branch to a memory address that doesn't exist. Before, you would get a hard freeze and Gecko.NET would lose communication with the Wii. Now, you can go to the BP tab and hit Step Into and it will show you what caused the ISI exception.
Program Exception is any time a fetched instruction cannot be executed. For instance, before if it would fetch .word 0x00000000, it would crash and lose communication. Now, you will get a Program Exception and BP tab Step Into will take you to the illegal instruction.
Program Exceptions are also useful for other reasons. There is an instruction called trap. trap will automatically cause a Program Exception.
You could in theory use trap to set up multiple XBP's. Change all of the instructions you want to BP on to trap. Then, when any of them are executed, the game will hit that BP. You will have to restore the original instruction in order for the game to continue execution.
Gecko.NET 0.66.8
http://geckowii.googlecode.com/files/Gecko dNet 0.66.8.zip (http://geckowii.googlecode.com/files/Gecko%20dNet%200.66.8.zip)
-fixed memview scrollbar (you're welcome Stuff)
-fixed 1932 send codes crash (you're welcome Bully)
-move unpatched debugger notification to the Tools tab (you're welcome Deathwolf); it tells you what code handler you're using now. You want 1931 or 1932. Other values are bad
-Wii crash notification with prompt for switching to BP tab
-auto-reset code handler prompt if the crash happened inside of it
-1931 patch: skip code handler if at breakpoint; can now debug codes that crash the code handler (e.g. C0 code that crashes)
---
To see an example of the new 1931 and 1932 patches, send the following C0 code.
C0000000 00000001
00000000 4E800020
This will cause a crash on .word 0x00000000 in the code handler. 1931 and sometimes 1932 would fail hard on this code. But with the new patches, once you send the code, you'll get notified that the Wii crashed and it will ask if you want it to switch to the BP tab. If you say yes, it will show you the instruction that crashed. Since a C0 code is in the code handler, it will also ask if you want to reset the code handler. You should say no this time (because it was a code crash) but sometimes you might want to say yes (if it was a debugger crash). Go to disasm tab and nop the .word 0x00000000. Then the game will recover.
Gecko.NET 0.66.9
http://jafile.com/uploads/wiiplaza/gecko_dnet.exe
- fixed typo "No USB Gecko connection availible"
At least it´s done now...
Hey guys I'm back. I understand that this has stopped moving forwards. Bully, have you worked on this more? Have you put your magic to use more? Anybody else? It seems that I'll have to make another post to inspire more work to be done on this almost perfect program.
Quote from: Patedj on December 22, 2012, 12:15:21 AM
Hey guys I'm back. I understand that this has stopped moving forwards. Bully, have you worked on this more? Have you put your magic to use more? Anybody else? It seems that I'll have to make another post to inspire more work to be done on this almost perfect program.
I PM'd dcx2 a little while back and he said he'll release the updated source code for Gecko.NET. He said he'll try to work on it during the holiday break. So, after it gets released, maybe the project will move forward again... Hopefully... :p
The show must continue ;D
Btw. I can only do text fixes for now, nothing else (hexeditor *cough*)
I use VS 2012 Premium so I can open the project and build it etc if needed?
Any progress on getting the source posted?
I remember when I updated to 0.66.8 from whatever I was using before their was a massive increase of how fast the dissembler tab would skip unmet breakpoint conditions, what version was this first implemented in? Another speed increase like that and it might be possible to isolate an individual read/write from/to a stack address