Code search not finding values??

[Nuke]

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.

[Link]

but 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.

[strakn]

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

[giantpune]

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

[Nuke]

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.

but 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.

[dcx2]

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

[Link]

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#.

[megazig]

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.

[Bully@Wiiplaza]

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...  :(

[Nuke]

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.

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...  :(

[dcx2]

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.

[Link]

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.

[dcx2]

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.

[megazig]

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

[dcx2]

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.