MPSEND delivery guarantee broken

Interesting... Did you try rewriting the code so it tries to receive until it gets a result not -1? It's possible it somehow got out of order, I guess... Could definitely be a bug, though. Is this behavior consistent?

I have run the code 8 times with identical results. I have tried MPRECV several seconds after the end of the test, and still gotten S%=-1; if the message hasn't come after several seconds, I doubt it ever will. I have also tried changing the first loop to TO 200, the WAIT to 440, and I get the strings "1" to "14", and "200", and nothing else. It seems there is no limit to the number of MPSEND messages that can get lost.

Seems like there's a maximum of 15 packets send, and if a 16th is sent, it overwrites the 15th. That would explain it - when you send 200, every number from 15 to 199 is overwritten with the next one. Questions that arise (for me): * Why is it 15 and not 16? * Why is there no error? According to the reference, sending the 16th packet should result in Error 42.

- A large number of MPSEND calls in a short period will result in an error * Communication buffer overflow 42: Communication buffer overflow (an overflow has occurred in the buffer for sending MPSEND)

* Is the same buffer used both ways? I.e. if both 3DS's send 20 packets simultaneously, then read, will they each get 15 from the other or will they get 15 in total between the both of them? * What happens when 3 devices are connected? This requires a crapton of testing.

- A large number of MPSEND calls in a short period will result in an error * Communication buffer overflow

Yes, about as useless a piece of documentation as it is possible to write. What is a large number? What is a short period? "There is an error. It will occur sometimes. It might not." Significantly, it does NOT say (in that quote) that the 16th packet should generate the error. The 16th packet could occur an arbitrary amount of time later, longer than any reasonable interpretation of "short period", and the problem still happens. It is another part of the documentation that is broken with regard this result, "Delivery of sent data is guaranteed, but with a delay".

* Is the same buffer used both ways? I.e. if both 3DS's send 20 packets simultaneously, then read, will they each get 15 from the other or will they get 15 in total between the both of them?

A 3DS will receive the messages it sends. If two 3DSs each send 20 messages, there will be a total of 40 messages: each will have the 14 earliest, and the one latest, as determined by each (they may disagree on the order, and wind up having a different set of messages in the end). 5 MPSENDs in the same frame always gives Communication buffer overflow error. Looping with VSYNC 4 and 4 MPSENDs right after will cause an error, but sometimes not for a couple of seconds. VSYNC 5 appears to work for many seconds. So, it appears there is a transmit buffer of size 4 that gets emptied every 4-5 frames (EDIT: perhaps more accurate to say, it takes a single message typically between 1 and 1.25 frames to transmit), and a receive buffer of size 15. A transmit buffer overflow causes an error, a receive buffer overflow is undetectable, in general.

- A large number of MPSEND calls in a short period will result in an error * Communication buffer overflow

Yes, about as useless a piece of documentation as it is possible to write. What is a large number? What is a short period? "There is an error. It will occur sometimes. It might not." Significantly, it does NOT say (in that quote) that the 16th packet should generate the error. The 16th packet could occur an arbitrary amount of time later, longer than any reasonable interpretation of "short period", and the problem still happens. It is another part of the documentation that is broken with regard this result, "Delivery of sent data is guaranteed, but with a delay".

Completely agree. The documentation of these commands is completely unsatisfactory, and I've noticed this in the past.

* Is the same buffer used both ways? I.e. if both 3DS's send 20 packets simultaneously, then read, will they each get 15 from the other or will they get 15 in total between the both of them?

A 3DS will receive the messages it sends. If two 3DSs each send 20 messages, there will be a total of 40 messages: each will have the 14 earliest, and the one latest, as determined by each (they may disagree on the order, and wind up having a different set of messages in the end).

Thanks, I didn't know that (all I know about SmileBASIC is from the documentation). Clears some stuff up!

5 MPSENDs in the same frame always gives Communication buffer overflow error. Looping with VSYNC 4 and 4 MPSENDs right after will cause an error, but sometimes not for a couple of seconds. VSYNC 5 appears to work for many seconds. So, it appears there is a transmit buffer of size 4 that gets emptied every 4-5 frames, and a receive buffer of size 15. A transmit buffer overflow causes an error, a receive buffer overflow is undetectable, in general.

That sounds correct, by the behavior you described. I wish we could get some confirmation and/or better description from SmileBOOM, is there any way to ask them specifically about this with a high chance of response?

sigh - I just made another discovery. It can happen that a console executes two MPSET commands in a row, and the effects of the second are observed with MPGET before the effects of the first. I can't find any particular part of the spec that this violates, but -- expletively expletiving expletive.