Max Number of Peek/Poke Operation Per Second

[biolizard89]

How the program would work, roughly, would be, every few frames (I figure 10Hz is good enough), dump some variables which are useful to sync the Wiis (Wiimote data, plus some stuff like player XYZ coords, player health, player XYZ velocity, etc. -- what I sync depends on the game), and send the resulting data over either TCP or UDP to a remote player (TCP would be easier to program, as I wouldn't have to worry about data getting lost, but UDP would probably be faster... haven't really made that decision yet).  When data arrives from a remote player, upload it back to the Wii.  The setup is pretty similar to what Sappharad did with GC-Online-Tunnel using GCNrd, although my program would probably support more advanced stuff than what Sappharad did, since his program was basically a proof-of-concept put together in about 4 days.  E.g. I would like my program to support pointers and conditionals (which would probably put more load on the USB connection, but hopefully that isn't a big deal).  If a USB error occurs as Link said, I can wait until the next frame to send/receive the data, as long as the network connection between the PC's is reliable.

So yeah, Wii1 <--USB--> PC1 <--TCP/UDP--> PC2 <--USB--> Wii2.

[biolizard89]

(Sorry for the double post)

Here's what I think would be a nice feature in the code handler and WiiRD.  Have a pointer version of the poke/upload/peek/dump commands.  Data sent would be the pointer address, offset, data size, and data.  This would, IMHO, make things a lot more efficient, as the PC would not have to parse the pointers and go back to the Wii to get the correct values.  And in cases like mine, where efficiency is key, it could help greatly.  It would also help deal with pointers in the GUI, since you could poke a pointer value directly, instead of navigating to the correct address by yourself, making it easier to evaluate the results of a pointer search.

Do you think this would be useful?

Thanks!

[Link]

Phew.. there is some idea like that in the plan for the current WiiRd GUI. However, currently things are still parsed on PC side. Parsing on Wii side.. well.. possible.. however, most of the time our code handler wasn't optimized for functionality and speed.. it was optimized for being as small as possible while still having some proper functionality. However: you can modify the code handler.. download the sources of Gecko OS 1.06f which are publically availible.. kenobiwii.s or so (can't remember the exact file name) is the code handler. You can modify it and recompile Gecko OS. THen it would have your wished functionality.

[biolizard89]

Thanks for the info.  Unfortunately, I do not know any ASM.  :-[  I can do C/C++, but ASM is something that I have never been able to get good at.  Thus, I can tell by the comments sort of what is going on at a high level, but actually adding a command... not something I could really do.

I understand that the code handler has to be very small; otherwise, it would probably impact compatibility.  If I recall correctly, the code handler is about 4KiB right now; any idea how much Wii-side pointer upload/dump commands would add to that?  Would the difference be likely to screw up games?

I'm certainly not going to ask you to compromise game compatibility just for a minor feature I'd like.  But if you felt like adding the feature, I certainly wouldn't complain.  If nothing else, I could probably find someone who knows ASM who would be willing to make that modification for me.

Thanks!

[Igglyboo]

If the parsing was done wii side i wouldn't care if my fps dropped a bit.

[Link]

I understand that the code handler has to be very small; otherwise, it would probably impact compatibility.  If I recall correctly, the code handler is about 4KiB right now; any idea how much Wii-side pointer upload/dump commands would add to that?  Would the difference be likely to screw up games?

Technically speaking we'd have place to add such a command. The main problem is, if we really want.. we wanted to keep the code handler small to allow as many codes as possible (256 lines as of now). Adding commands will reduce this so we'd defenitely not add that command to retail versions as of now... I'll have to see for other things though.

[biolizard89]

Hmm, does ASM make it easy to do conditional compilation like C/C++'s #ifdef directive?  If so, maybe it could be added to the source code but disabled in official builds, maybe with an alternative build available with the feature included?

While I'm talking about additional features for the code handler, something else that would be cool would be adding a code-type that dumps a certain area of RAM over the USB Gecko (without waiting for the PC's response).  Combining that with a conditional counter code, the code handler could then dump all the data I need every, say 6 frames, without the USB Gecko overhead of repeated dumping.  Have 2 sub-types, one for base address and one for pointer, and have the value part of the code be the number of bytes to dump.  This would actually be useful for WiiRD GUI as well, as a hacker could "watch" 4-5 different RAM values while hacking, without USB Gecko overhead.  And again, this could be a conditionally compiled option so that people who are just using the Ocarina feature can have as many codes as possible.

And by the way, thanks for at least taking my ideas seriously.  There are so many developers out there who dismiss ideas without discussion because not many people would use a feature, and it's nice to see that, regardless of whether my suggestions get implemented, you're willing to discuss them.  We need more developers like that, so thanks.

[Igglyboo]

I understand that the code handler has to be very small; otherwise, it would probably impact compatibility.  If I recall correctly, the code handler is about 4KiB right now; any idea how much Wii-side pointer upload/dump commands would add to that?  Would the difference be likely to screw up games?

Technically speaking we'd have place to add such a command. The main problem is, if we really want.. we wanted to keep the code handler small to allow as many codes as possible (256 lines as of now). Adding commands will reduce this so we'd defenitely not add that command to retail versions as of now... I'll have to see for other things though.

You could implement Gecko OS to read the codes and see if it needed the new code handler, newer codes would need the new code handler so it would have less lines.
If it didnt have newer codes just run the old handler.

[biolizard89]

You could implement Gecko OS to read the codes and see if it needed the new code handler, newer codes would need the new code handler so it would have less lines.
If it didnt have newer codes just run the old handler.

Actually, yeah, that's probably better than my idea with the conditional compilation.  Just have both in GeckoOS and decide which one to load.  That said, the suggestions I made would probably be used in conjunction with WiiRD or some other way of dynamically using them through USB Gecko, so rather than reading the Ocarina code list to determine what code handler to use, just give users a choice of "Standard" or "Debug" handlers.  Make Standard the default, maybe bury it in a menu so that people who don't know what they're doing will ignore it, and make it clear in the documentation that if you want to use the advanced debug features that my suggestions would use, you need to tell GeckoOS to use the Debug handler.  People who are debugging probably don't need 256 lines of codes, and people who are just using the Ocarina features probably don't need those debugging features, so that sounds like a win-win.

Does that sound possibly workable?

Thanks!

[biolizard89]

(Double post again, sorry)

Actually, it just occurred to me that a feature which might minimize the need for the aforementioned features would be a command for dumping/uploading the Gecko Registers.  I know you can do this now with a hardcoded address, but a future-proof option would be a lot safer.  If I had the ability to dump/upload the Gecko Registers, I could rig up a simple WiiRD code that copied that data into and from the actual variable addresses, and I'd be able to use pointers with minimal USB Gecko transfer.

This would also be useful for debugging codes that use the Gecko Registers.

Does this sound like a useful feature?

Thanks!

EDIT: Actually, now I'm not sure... are the Gecko Registers' addresses safe to hardcode?  The code type documentation implies that they are safe.  Is this true?  Thanks.

[biolizard89]

(Apologies for the repeated posts here)

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.

I'm assuming this is FT_IoCtl.  From looking at what arguments it takes, it looks like I can give it a send and receive buffer and it will process both simultaneously.  This would be quite helpful.  However, there is one argument that I'm clueless on.  What the heck does the DWORD dwIoControlCode argument do, and what value(s) can it accept?  If you know, would you mind sharing?

Thanks.

[biolizard89]

(Please forgive me for the repeated posts, I'm not trying to spam here)

Okay, here's a performance question.  If, every frame, all I do is upload 8352 bytes and dump 288 bytes, is this rough level of USB Gecko activity going to slow down the game significantly?  I assume changing the packet size would be necessary to get high efficiency, but that isn't a big deal.  Any idea how much data I can upload or dump in one operation each per frame and not slow down the game significantly?  This is pretty much the maximum level of usage I can imagine, I'm wondering if it would be anywhere close to workable.

Thanks!  :)

[Link]

As far as I remember upload/download data is sent in blocks.. uploads are in 0xF80 blocks, downloads in 0xF800 blocks. As long as your below that block size, uploads are done in one cycle. Otherwise two or more!