The USB Gecko that I'm using runs extremely slow. I timed the amount of time it takes to do a mem1 dump, and it took 8 minutes, 30 seconds.
I've tried both the default drivers from windows update, and the newer ones that one of the stickies links to, as well as both the stable and beta versions of gecko.net.
Am I doing something wrong, or does it just take that long?
That would depend on the game you're trying to get the dump from, because some are really quick and some have taken in excess of 5 minutes for me anyway.
I think you'll need to post more information so that we can better help you.
i.e. System specs, game you're ripping etc.
The game that took 8:30 was Super Smash Bros. Brawl.
I've tried SSBB, SMG, and Xenoblade, but all of them take a really long time.
As far as computer specs, I don't really see what you would want from that, but I've got a Gateway DX4831-03
http://www.newegg.com/Product/Product.aspx?Item=N82E16883113119
Edit: Timed a dump from Super Mario Galaxy, and it took the same amount of time as Brawl +- 5 seconds
You're getting 25165824 Bytes / 510 seconds = ~50kBytes/sec = ~400 kbits/s (I'm not including some packet overhead but it's relatively minor) The FTDI chip in the USB Gecko is Full-Speed, meaning 12 Mb/s (theoretically), but the unlocked EXI bus is should be able to reach 16 Mb/s (theoretically, accounting for the interleaved command bytes).
I just timed my own dump out of curiousity. I did an unknown search of all MEM1; the "unknown" part is important because it only counts the time dumping and not searching/comparing memory (which can take significantly longer). It took about 41 seconds for me, which is almost 5 Mb/s, so I would say something is wrong.
It shouldn't matter too much, but if you have a lot of other USB devices consuming bus bandwidth at the same time, it could result in slower transfers, but I did this with a USB video adapter running.
Go to the tools tab in the beta version to see what code handler you're using. Try to time it again with an Unknown search and a 1931/1932 code handler. You should get 6291456 results.
I don't know what happened, but it's going faster now. It took about 30 seconds to do an entire mem1 dump. It's not that stable though. It keeps freezing the wii all the time.
The code handler it displays is "?????"
And with the beta gecko.net, I get an unhandeled exception because of an array out of bounds error.
[spoiler]See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at GeckoApp.MainForm.InstallWiiBPHandlers()
at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnShown(EventArgs e)
at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
at System.Windows.Forms.Control.InvokeMarshaledCallbacks()
************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5448 (Win7SP1GDR.050727-5400)
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:/Users/Barney/Desktop/Gecko/gecko_dnet.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5446 (Win7SP1GDR.050727-5400)
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.5447 (Win7SP1GDR.050727-5400)
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.5420 (Win7SP1.050727-5400)
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.5420 (Win7SP1.050727-5400)
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.5420 (Win7SP1.050727-5400)
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]
Try using Gecko OS 1.9.3.1 instead. Your code handler is unknown and will be prone to all kinds of bugs.
Quote from: dcx2 on January 01, 2012, 09:43:31 PM
You're getting 25165824 Bytes / 510 seconds = ~50kBytes/sec = ~400 kbits/s (I'm not including some packet overhead but it's relatively minor) The FTDI chip in the USB Gecko is Full-Speed, meaning 12 Mb/s (theoretically), but the unlocked EXI bus is should be able to reach 16 Mb/s (theoretically, accounting for the interleaved command bytes).
I just timed my own dump out of curiousity. I did an unknown search of all MEM1; the "unknown" part is important because it only counts the time dumping and not searching/comparing memory (which can take significantly longer). It took about 41 seconds for me, which is almost 5 Mb/s, so I would say something is wrong.
It shouldn't matter too much, but if you have a lot of other USB devices consuming bus bandwidth at the same time, it could result in slower transfers, but I did this with a USB video adapter running.
Go to the tools tab in the beta version to see what code handler you're using. Try to time it again with an Unknown search and a 1931/1932 code handler. You should get 6291456 results.
The FTDI chip is rated for 1Mbyte/s = 8Mbit/s for D2XX transfers, so it won't get near the 12Mbit/s that the Full-Speed USB spec is rated. http://www.ftdichip.com/Products/ICs/FT245R.htm
Either way, I agree that 400kbit/s is not normal, and the nonstandard code handler is certainly a suspect.
Okay, I grabbed a newer handler, and now it shows 1931. Before I was using an older handler, or using gecko os 1.9.1. It's all working properly now as far as I can tell. Hopefully it's more stable now.