| | Re: RCX to RCX NQC
|
|
(...) Ahh, now I understand why it is called a "toggle bit" - I somehow misinterpreted this to mean a new command had the toggle bit set (to 1), and if the sending unit doesn't recieve a reply it should re-transmit the command with the toggle bit (...) (19 years ago, 14-Sep-05, to lugnet.robotics.rcx)
|
|
| | Re: RCX to RCX NQC
|
|
(...) I'm pretty sure, both the remote, and the send message commands only have one op-code, and are done differently from the rest. Steve (19 years ago, 14-Sep-05, to lugnet.robotics.rcx)
|
|
| | RE: RCX to RCX NQC
|
|
The message "toggle" bit was a good concept that has very limited value in practical use. I guess the intent was to prevent unexpected behavior when a PC program attempts retransmission after a message failure. Suppose the failure condition was that (...) (19 years ago, 15-Sep-05, to lugnet.robotics.rcx)
|
|
| | RE: RCX to RCX NQC
|
|
There's another little problem that you may need to program around. There's a bug in the ROM firmware that could end up requiring a 30-millisecond delay between when a RCX sends out a message and when you should start sending the first character of (...) (19 years ago, 15-Sep-05, to lugnet.robotics.rcx)
|
|
| | RCX to RCX NQC
|
|
One last email on this topic. There's new opcodes in the Swan firmware to support many data bytes in a single "mailbox" message. The standard firmware supports "mailbox" messages with a single byte parm. I found this very restrictive in building RCX (...) (19 years ago, 15-Sep-05, to lugnet.robotics.rcx)
|
|
| | Re: RCX to RCX NQC
|
|
(...) And that explains why I was having so much trouble with my custom Tcl based uploader in high speed mode. I fixed it a while ago by adding a slight bit of extra time between messages, but never got to the root of the problem. Thanks Dick! (...) (19 years ago, 15-Sep-05, to lugnet.robotics.rcx)
|