Max Number of Peek/Poke Operation Per Second

[biolizard89]

Hi, got a question which may sound stupid, but here goes.

I'm interested in an application on the PC side which needs to send a large amount of peek and poke commands to WiiRD.  I'm wondering how many 32-bit peek and/or poke commands can be executed per second with WiiRD, without adversely affecting the speed of the running game.  As a rough guess, I'm hoping for roughly 18 peeks plus 18 pokes per frame.  Less could be worked with, more would be excellent.

Thanks!

[kenobi]

I've no clue what would be the max. What do you want to achieve ?
Because that's what the code handler is made for anyway, peeking and poking around...

[Link]

the maximum is not limited myself.. though when the game is running the code handler is executed 60 times a second - once for each frame.. do you really mean 36 operations PER FRAME? Or do you mean 36 operation (18 poke+18 peek) per second. I guess per second might be possible if you develop a very fast program. WiiRd isn't using the required environmenrts for that and defenitely won't be able to do that.

[biolizard89]

Hmm, ok.  What I'm interested in is basically in the style of Sappharad's program GC-Online-Tunnel.  The idea is, every frame (or every few frames, if trying to conserve bandwidth), peek the Wiimote data from the game, along with some game-state data to keep it synced (XYZ coords of the player, etc.), send that over the Internet or a LAN, receive such data from the remote player, poke that data into the local game, and repeat.  The effect would be that any Wii game would be playable online, if a hacker determined the addresses to peek/poke to keep it synced.  Based on my very rough estimates, given my experience in doing this for Smash Bros Melee with Fuzziqer Software's GCARS-CS, is that it could require up to 18 32-bit chunks of data for the more complex games to keep it synced.  Meaning 18 peeks and 18 pokes, each frame that my program runs.

So what I'm understanding from you is that the WiiRd PC-side programs aren't capable of doing this, and I would have to write a very fast program myself to do this, but the Wii-side code could possibly handle this.  Is this correct?

How many peeks/pokes can the Wii-side code handler process per frame, without drastically slowing down the game?  (I understand that it executes every frame.)

Thanks, and I apologize again for the weirdness of this question.

[biolizard89]

(Sorry for the double post)

So I've been looking at usbgecko.pas a bit.  I assume that if I call this code directly, rather than going through WiiRd, it would be much faster.  Still unsure of some things, so I hope someone can answer some questions.  Assuming I use the code in usbgecko.pas, roughly how many peek/poke commands could I execute per frame, and is this limited by the code handler running on the Wii, or is it limited by the bandwidth of the USB Gecko?  Are there any optimizations that could be made to usbgecko.pas which would increase the number of commands per frame?  Could the peek commands be queued into the USB Gecko before the data is returned back to the PC, or would that overflow a buffer?  Would pausing the game before executing the other commands, and unpausing after the commands have executed, help increase the commands per frame, or is that irrelevant?  I don't know any Delphi; is there a C/C++ version of usbgecko.pas somewhere, or would creating a DLL be my best option for using this code from a C++ program?

Thanks again!

[Link]

Technically, it shouldn't be too hard to rewrite usbgecko.pas to C/C++ - the functions you need to port are connect, initgecko, peek and poke - and there is also public C code over at http://www.usbgecko.com - look at the memory dumper - it has some C source code.. you just need the FTDI libraries and I'd happily assist you in what data to send to efficiently get high speed pokes/peeks.

[biolizard89]

Cool, I took a look at the memory dumper source; it looks like it would be helpful.  I can't find the C/C++ version of libftdi.pas, though, which it looks to me like it's necessary for some of the code in usbgecko.pas to work.  Any idea where I could find that code?

So for high-speed peeks/pokes, any idea how many would I likely be able to execute per frame, if I optimize my program well?  Would 36 operations, executed every 6 frames or so, be likely to slow down the game unpleasantly?

Thanks!

[Link]

Download the newest driver package for the libftdi chip which is in the USB Gecko:

The zip archive will contain ftd2xx.h - which is the header file for ftd2xx.lib n the i386 and amd64 directories (probably i386 as that's the platform must of us still build for). Then all commands should work and the mem dumper should be compilable.

[biolizard89]

Cool, I'll be sure to check that out.  The connect code in usbgecko.pas and the C/C++ memory dumper seem to have some differences; any reason for that?  E.g. some chunk size stuff, some other stuff that I noticed but don't remember offhand.  Would I have to port the usbgecko.pas version to C++, or would the existing memory dumper connect code work fine?  They seem to use a different Wii executable (memory dumper doesn't use the official GeckoOS, it uses a .elf that comes with the dumper); would that account for the differences?

And I apologize for repeating this question, but my pursuit of this project heavily depends on the likely performance of the setup, so: for high-speed peeks/pokes, any idea how many would I likely be able to execute per frame, if I optimize my program well?  Would 36 operations (18 peeks, 18 pokes), executed every 6 frames or so, be likely to slow down the game unpleasantly?  What about running the 36 operations every frame (which would be overkill and I don't need, but would be kickass)?

Thanks again!  :)

[Link]

That many operations will most likely slow down the process.. especially.. a peek is seperated into multiple commands:

-peek announce (don't remember the ID)
-waiting for reply.. should be AA = success
-sending address (big-endian)
-waiting for reply

Thus I guess 36 operations every frame will slow down the game completely.

For the headers.. the code of the mem dumper works.. the chunk size was just tweaked around in our cases to get maximum stability. Other than that however, nothing should be changed - it is just splitted into connection and initialization - basically it's good to reinitialize the USB Gecko before several commands - like poke.

[biolizard89]

Hmm, ok, so since I need to do around 36 operations every 6 frames or so, would there be a lot of slowdown if I averaged it and did 6 operations every frame?  Any estimate of how much slowdown that would cause?  (A rough estimate is fine, e.g. would it reduce the speed by 80%, 50%, 20%, etc.?)

As for the peek operation, is there any particular practical reason why it needs to split it into two commands?  Would it be possible to "queue" the commands by sending the second command before the response to the first one is received, so that the moment the Wii sends the AA, it already has the following data, so that it can continue immediately?  If this is not possible, is there any particular practical reason for this setup?

Sorry for the abundance of questions here.  :)

Thanks!

[Link]

It might work by sending 5 bytes in one.. I must admit though that it is untested.

The reason for this setup - simple: we always have to expect commands to fail.. so for example if another command is running for some reason (crash or something similar on Wii side) we wouldn't receive AA.. in that case we try to send FF first - meaning "sendfail" which should reset all running commands - so that the Wii can reply properly again..

[Nuke]

Hi,

yes you can do queue commands and use none synchronous transmission, and would work well if your sending small packets, because the usb chip is buffered i.e has 256 byte receive buffer and a 128 byte transmit buffer. It is only when the buffer is full and your sending larger packets that it needs to be handled correctly.

As USB Gecko was designed to be none IRQ driven you should really poll the FIFO buffer before sending though to make sure the buffer is not full.

You will have to experiment with your protocol, as there many ways to handle things. There is even an undocumented command to send and receive data at the same time, if your having problems with speed.

It sounds an interesting project good luck with it.

Hmm, ok, so since I need to do around 36 operations every 6 frames or so, would there be a lot of slowdown if I averaged it and did 6 operations every frame?  Any estimate of how much slowdown that would cause?  (A rough estimate is fine, e.g. would it reduce the speed by 80%, 50%, 20%, etc.?)

As for the peek operation, is there any particular practical reason why it needs to split it into two commands?  Would it be possible to "queue" the commands by sending the second command before the response to the first one is received, so that the moment the Wii sends the AA, it already has the following data, so that it can continue immediately?  If this is not possible, is there any particular practical reason for this setup?

Sorry for the abundance of questions here.  :)

Thanks!

[biolizard89]

Okay, so based on that, I would probably send all the data for the frame to the Wii, and then receive the replies as they come back.  If an error occurred, I would just ignore that data, send the fail command, and wait until the next frame.  This sounds like it would work, since my program should still work fine if an occasional frame of data gets dropped.  Does this sound to you like it would work okay?

Also, it occurred to me, some of my 32-bit variables are next to each other in memory (e.g. a player's X, Y, and Z coords are right next to each other), so if I ask the Wii to dump 12 bytes, would that be faster than peeking 3 32-bit values?  If so, about how much faster?  Similarly, about how much faster would uploading 12 bytes be compared to poking 3 32-bit values?

Nuke, when you say 256byte receive and 128byte send, is this from the point of view of the PC?  I.e. 256byte buffer for Wii-->PC and 128byte buffer for PC-->Wii, or is this the other way around?  Sorry if I'm being dense here.  To check if the send buffer on the PC side is full, is the function of choice FT_GetStatus?

As for this "undocumented command"... is this FT_IoCtl?  I could not find any info with Google on what it does; do you know how it works?  If so, would you be able to share?

Thanks for the info.

[Nuke]

It is buffered on the chip itself, the FIFO buffers.

You want to grab as many bytes as you can if its possible, the less amount of USB transmission the better. If you can grab 12 bytes at a time would be faster than grabbing 4 x 3.

about how well your program would work, it would be hard for me to say as its all speculation I don't know how a tunneling program would work. How do you actually share the player data with the other person?