Emulator Issues #6006
closed
USBGecko Emulation Sends 1 Byte at a Time
Added by dantarion almost 12 years ago.
Issue type:
Feature request
Relates to performance:
Yes
Relates to maintainability:
No
Description
The USBGecko Emulation seems to send one byte from its send buffer at a time, as opposed to clearing the send buffer as soon as it can.
I am writing a python lib that communicates with a USBGecko over a COM port, and I am using the same code to communicate with Dolphin over its TCP port based USBGecko Emulation.
The same code works with both the USBGecko, and Dolphin, but dolphin returns about 512 bytes a second, meaning it is pretty much useless for what I want to do, which is port GeckoDotNet to be able to connect to Dolphin
(no offense to Dolphin's debugging tools, but I like using what I like using :D)
I am working on a patch to send in to fix this, but I am having issues compiling dolphin on Windows 8 with VS2012 Express
- Status changed from New to Accepted
- Issue type set to Feature request
- Priority set to Normal
- Relates to performance set to Yes
- Operating system N/A added
You are quite correct. The implementation of USBGecko isn't quite the best, and in it's current implementation, it is locked at ~500byte/s depending on system sleep accuracy.
2I have begun work on this.
I also think I am going to write a guide on compiling Dolphin on Win8+VisualStudio2012, you have to do some weird things like recompile PortAudio right now and its pretty awkward.
Right now I am changing the code to build a char array by emptying the fifo queue, and sending that packet. I am now seeing speeds that flat out DESTROY using an actual USBGecko. I will submit a patch once I make a USBGecko Emulation unit test so I can that everything works.
please make sure you don't break other things, like gdb and existing apps / libs which use usbgecko.
That is the goal, however, I am pretty sure any app that using USBGecko will have a massive speed improvement from receiving more than 1 byte per packet, and if those apps work fine with the current borked implementation, they should have no problem recieving the same data in larger chunks.
This is so small im going to just paste it in here....
With this code, I can use the USBGecko interface to dump all of mem1 in 14 seconds. While that is slower than just dumping memory from dolphin, I am going to be using my code to navigate data structures in memory, which I can't do with ANY tools that exist at this point.
I don't have any other apps to use with this to test if it breaks anything, all I know is that this fixes my problem.
if (send_fifo.size())
{
char* packet = new char[send_fifo.size()];
int i = 0;
while(send_fifo.size())
{
packet[i++] = send_fifo.front();
send_fifo.pop();
}
if (client.Send(packet, sizeof(u8)*i)
== sf::Socket::Disconnected)
client_running = false;
//send_fifo.pop();
}
- Status changed from Accepted to Fixed
This issue was closed by revision 123035a192d8.
This issue was closed by revision 123035a192d8.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Anonymous 
Updated by