WiiRd forum

Ok so I just purchased a usb gecko se.  I installed the drivers, and can get wiird and gecko dotNEt to connect, although usually
I would have some difficulty getting them to connect (needing to unplug usb cable when it said it wasnt connected then plug it back
in and retry)

Now what I realize is that performing code searches with both wiird and geckodotnet are not finding all of the values and sometimes the values are wrong. Example I know there is the value 0x00000008 at address 0x80A1B058 but when i do a 32bit code search for that value it doesn't find it and usually doesnt seem to find any values over 81 mem area. I know the value is there I can see it in memory viewer it will change if i poke it and i can see the change on the screen, but it just wont show up in the code search for wiird or gecko.net

I have tried updating the drivers, I have tried on 3 different computers now (xp,vista and 7) same issue.
I have reprogrammed the eeprom with .ept file that nuke linked to in another thread.
The only other thing I can think of besides a defective usbgecko is the cable, its the one that came with the usb gecko
if trying another cable(s) doesn't work, Is there anything else I can try before returning the unit?

Edit--

If I narrow the search parameter down to a very small search, sometimes it will show the value of a known location.

Edit 2 -

I have tried 2 other cables, shorter ones with ferrite beads on them and still no luck.

That's odd...

Try pausing the game.  Then do an unknown search.  Then do an equal search.  Since the game is paused, all values from the first dump should be identical to the second dump.  Subsequent equal searches while the game is still paused should result in the same number of search results.  If you start losing results, then something is definitely fishy.

Thanks for tip, that should prove that the data is somehow being corrupted.  The data seems to not get corrupted when dumping small chunks as memory viewer does, or when chan ging the default search parameter to very narrow field. It will be a few hours before im back at the wii.

I have sent an email to usbgecko support hopefully they will have input on my problem.

That problem happened during WiiRd development.. however, with new USB Gecko drivers it seemed to fix itself kenobi and me were unable to reproduce it on one day and well.. logically we were happy. Please try replacing the USB cable just for the sake of testing, otherwise try a different USB port (not the one directly next to the one you're using, a totally different one, it should be on a different internal USB hub  -normally each PC has 2 USB ports per USB hub) - it will be worth a try I guess.

He said he tried different cords and PCs.  Although you bring up a good point...where did he get the drivers?

I got the drivers right from the chip manufactures website.
http://www.ftdichip.com/Drivers/D2XX.htm

Also on the xp machine i tested it already had an older version of the ftdi drivers 2.04.x

I did what you suggested dcx2, starting an unknown value search while paused, then doing consecutive equal to searches,
the found results kept going down, I even tried executing a breakpoint intead of using pause (probably same thing) and
got the same diminishing results. I did this with both gecko.net and wiird gui, same results.

I did a resynchronizing comare to the dumps in hexworkshop and there were many deletions,insertions and replacements.

I am really at a loss, as to the cause of this, the only two variables I have not changed are the wii and the usbgecko, unfortunatley
there is no other wii i can test with.

Ok so I used the FTClean utility to completely remove the drivers, then I installed an older version of the drivers and get this message

[spoiler](http://img638.imageshack.us/img638/6277/wiirderror.jpg)[/spoiler]

Used FTClean again and tried newest driver and this is what It what it says in wiird 0.9.3 it just stays there trying to reset
[spoiler](http://img6.imageshack.us/img6/6/wiirderror2.jpg)[/spoiler]

I can no longer even get a connection to the usb gecko

Nuke I see you have been active within the past few days, If you see this please provide some input, I have sent an email to [email protected] but have not heard anything back.

You seem like a competent fellow, so I trust you can follow these instructions, but be careful.  This is how I remove drivers from Windows.

While the USB Gecko is connected (I don't think it needs to be connected to the Wii, just the PC), go to device manager (tip: start -> run -> devmgmt.msc ) and uninstall the device.  Once it is uninstalled, remove it from the PC.

From admin command prompt, run pnputil -e.  You will see a list of all the drivers you have installed.  Note the driver package provider; you're looking for FTDI (if there are multiple instances, you want all of them).  Once you find them, note published names, oemXxx.inf

Then, from the same command prompt, run pnputil -f -d oemXxx.inf.  This will remove the driver from the driver store, so that Windows will ask you for the driver when it is connected again.  Do this for each instance of FTDI.

Now when the device is connected, Windows will ask you what to do.  I recommend just getting the driver from Windows Update.

Ok I followed your steps but there was no driver package provider for FTDI. (Probably beause the last thing I did was use FTClean to remove the drivers after my previous troubleshooting failed)

So I reinstalled the drivers again and then removed them with your method, I connected the usbgecko and windows told me to insert the disk that came with it, I skipped that and told it I didnt have the disk, forcing windows to check online, Windows said it could not find any drivers online, so the only other option was to use ones I downloaded...no good.

For real, Windows Update didn't find the driver?  I know they have FTDI drivers.  That's so strange...

In Device Manager, go to the Properties of the device, Details tab, change the dropdown to "Hardware Ids".  What are the VID and PID?  I wanna see if they're different from the FTDI chip I use.

USB\VID_0403&PID_6001&REV_0600
USB\VID_0403&PID_6001

edit;

when i tried to update the drivers on the xp machine (the one that already had drivers preinstalled) when i pointed to the new drivers it said the best ones were aleady installed

0403:6001 looks good, I don't understand why Windows can't find the driver online...

I'm at a loss, sorry.

thanks for all your help dcx2.

I have received an email back from ian/nuke (i think they are the same) and have pointed him to this thread
in the hopes any steps to resolve this issue will not need to be repeated.

it is very discerning reading up on all the codetypes and trying to learn some basic asm,
then when the time comes to put it to use not being able to.

i had an issue with corrupted dumping also. ian pointed me at doing a tx check and i fixed the codehandler. a link is on the rvlution site for riivolution. it will need a mod to geckoos unless you run it from riivolution

Tomorrow I will spend the day to fix this. The handler mem dump routine has a bug, but Gecko.NET will also need editing for the update.

Might take a couple of days testing etc, before a public push though.

Sorry for the inconvenience.

asm is done. is it ok to give strakn access to hackers, as maybe will need to post some test builds.

strakn, what was the game you are having problems with? if it a metroid game i will kill you :)

update: code finished, just emailed brkirch the handler. I will post builds in hackers once we have them.

Quote from: Nuke on February 24, 2011, 02:42:56 PMbut Gecko.NET will also need editing for the update.

What would be required to change on that side - I notice dcx2 mentioned he also has quite limited time at the moment, in worst case, I do think I have a bit more time right now so I could also implement it and update the SVN build if required.

I have not tried any metroid games, the only games I tried were Wii Play, Wii Sports, Mario Galaxy, Call of Duty

Quote from: Link on February 25, 2011, 04:22:58 PM
What would be required to change on that side

i believe that the changed codehandler in megazig's version ended up putting the code buffer in a different spot.  so geckoDotNet needs to know the new code buffer location or somithing like this

Just the dump functions in usbgecko.cs, but i've now done it, I just need to test it with the new handler. I will post builds in hackers when I sorted it.

It should be much faster and also work with mono ok now. basically the problem was how it was syncing the packets which now i've removed. There is a trade off though, as might not be able to cancel a dump will have to wait until it finishes but at a later date I can add some timeout code on the Wii side, so if no response it will break out the loop in x seconds. Its pretty easy to do, just need to get the code tiny.

Getting it fixed, test is first though.

Quote from: Link on February 25, 2011, 04:22:58 PM

Quote from: Nuke on February 24, 2011, 02:42:56 PMbut Gecko.NET will also need editing for the update.

What would be required to change on that side - I notice dcx2 mentioned he also has quite limited time at the moment, in worst case, I do think I have a bit more time right now so I could also implement it and update the SVN build if required.

Someone should update the WiiRD console, too, for those folks who use WiiRDGUI.

Quote from: dcx2 on February 25, 2011, 06:41:25 PM
Someone should update the WiiRD console, too, for those folks who use WiiRDGUI.

I can see if I can do that! WiiRd uses the same dump function as Gecko.NET - just written in Object Pascal, while Gecko.NET is obviously C#.

Yeah, my update just moved some data/insns back so the code location moved. GeckoOS just needs that new location changed in source. The xml on rvlution shows the current location in memory from my assembling.

is it really possible to speed up the search?
Thought the memory slot can´t be faster than now... however, it wasn´t designed to transfer that big files as you may know.
Great to hear news about fixes and not losing results!! I wish I could help.
The only think I can do is creating hacks with assembly, but no programming experience at all...  :(

In this case, it will faster by

1. Removing synced packets
2. Lowering the packet size slightly to a more faster size. #f800 bytes is not the fastest even it is the highest possible amount.

other methods are:

1. Compress the throughput,
2. Use memory on the PC side instead of dumping to static files then searching.
3. Do the searches on the Wii side.
4. etc..

There are so many ways to skin a cat, but everything has a trade off, on time and available space. For example if the handler is to be kept in 6K of space then doing searches the wii side is going to be hard, the same with compression.

Quote from: Bully@Wiiplaza on February 28, 2011, 01:20:01 AM
is it really possible to speed up the search?
Thought the memory slot can´t be faster than now... however, it wasn´t designed to transfer that big files as you may know.
Great to hear news about fixes and not losing results!! I wish I could help.
The only think I can do is creating hacks with assembly, but no programming experience at all...  :(

Can we get an update on this?  What exactly did you do, megazig?  I can't find any details on your Riivolution code handler with a quick google search.

I've stumbled onto this again, and I've been considering work-arounds that can work with the current code handler.  It looks like a byte goes missing in the transfer, and yet all bytes still appear to transfer when it's over.  So I'm considering looking for some non-zero non-repeating 32-bit value at the end of each chunk of the dump and re-dumping that word to see if it's still the same, as a method of double-checking whether there was a corrupted transfer.

I verified that this affects WiiRDGUI, as well, but because WiiRDGUI breaks every dump into 1MB chunks, a missing byte early only screws up that MB.  With Gecko.NET, it dumps one big chunk, so a missing byte early on screws everything up after it.

I would also point out that I don't think Gecko.NET needs an update if the area where the codes go is moved.  I looked at how the cheats are generated and there's nothing about addresses; however, there's a command that tells the code handler "I'm sending you cheats", and I think it will put the cheats wherever it wants.

kenobi and me actually once had one idea.. maybe that would also be worth considering.. the code handler can be told to resend a package.. would it be possible to add a checksum even of the simple kind.. like change F800 bytes to F7FF - the lost byte would be used as a simple 1 byte checksum.. add each byte on Wii side with each other and miss the add carry. Simply form but might raise safety a lot as Gecko dotNET could reask for incorrect packages.

Yeah, I thought about doing a CRC or something like that.  Problem is, that requires changes on the code handler side.  Ideally, we want to use the same code handler.  A solution is beginning to crystallize in my head.

At the end of each dump, I'll look for the last two non-identical bytes (a "potential shift marker").  Then I'll peek at just those marker bytes from the USB Gecko again.  If the bytes do not match, then one was lost, and we can take corrective action.

I can then do a binary search for the last marker that matches; O(log(n)) for the win!  This will identify the byte that went missing.  I can then insert the missing byte from the peek, and shift the rest of the bytes so they align correctly.

As a bonus, since I'm shifting the array, the only thing I need to dump are bytes to peek at, so in practice the slowdown should be negligible.  If the dump is corrupted, it would take 27 binary search peeks to find the corrupted byte in a 64 MB dump.  At 60 DPS, that's about half a second at most

If the dump is not corrupted, we only peek once.

There is a small chance that when peeking for marker bytes, some value may change.  So we'll have to ensure the game is not running when doing a verified dump.

Sorry for the delay. Not as much wii time lately. I just added a small tx check on the send function

I take it back.  After some further testing, it appears as if the code handler is sending a duplicate byte.  A little tweaking and the same basic premise from above works.

It also looks like there's a second type of error; occasionally packets that are short by about 0x38 bytes.  That's okay, because we just send the Retry instead of Ack..except that the Retry will un-shift everything so at that point, so that it all looks correct.  So I'm not quite done tweaking it yet...but I'm getting closer.  The basic premise is there and it works much better, although it is not yet bulletproof.

Anyone following this thread should look into 0.64.4

http://wiird.l0nk.org/forum/index.php/topic,4886.msg67612.html#msg67612

Anyone following this thread should look into these code handler bug fixes.  They work with both WiiRDGUI and Gecko.NET

http://wiird.l0nk.org/forum/index.php/topic,8125.0.html