Ok, just a two byte saferam area it is. And, yes I know that the Cn2_Setup has to be called first. That was just a rough draft.

Ok, so do u suggest I scrap the idea of a slight freeze? And would halt be more efficient?
No, no delay on the receiving calculator is going to guarantee successful broadcast from another calculator to that calculator. A two-way or three-way handshake is the only thing you can use, combined with occasional broadcast retransmission.
Ok. No delay it is. And, I'll forgo the handshake in the beta and see how successful it is by just assuming the data is received.

However, i don't know if this qualifies as a two-way handshake, but once a calculator receives a join message, it returns the transmission, with a PTP version of its own join message.
That latter is a two-way handshake, which is the correct way to do things. Smile Very nice.
Great. Wink
ACagliano wrote:
Great. Wink
Is that all? Sad That's not really up to the standards of a quality Cemetech post, adding at least something to the discussion without simply posting for the sake of posting. Any more questions about CALCnet mechanics in the meantime? I believe you had a question about the buffer-clearing mechanism when data is sent, or was that resolved?
Well, I believe it was resolved. You said that the MSB of (SendSize+1) is reset upon completion of a PTP. That works for my purposes. Does the same apply to a broadcast?

Also, I'm requesting written permission to use cited quotes from the DSC7_SDK.pdf and/or CALCnet whitepaper in my game's usage guide.
ACagliano wrote:
Well, I believe it was resolved. You said that the MSB of (SendSize+1) is reset upon completion of a PTP. That works for my purposes. Does the same apply to a broadcast?

Also, I'm requesting written permission to use cited quotes from the DSC7_SDK.pdf and/or CALCnet whitepaper in my game's usage guide.
Permission granted. And yes, the same applies to a broadcast. The main difference from the sender's point of view between a directed (point-to-point) and broadcast frame is that a checksum exchange is not performed for a broadcast frame for obvious reasons.
Thanks, and ok. I also, meant to ask if it would be ok if I packaged DCS7.1 itself into the zip with this game, or would you rather I just link to it.
ACagliano wrote:
Thanks, and ok. I also, meant to ask if it would be ok if I packaged DCS7.1 itself into the zip with this game, or would you rather I just link to it.
I would rather you linked to it, especially considering Doors CS 7.2 is now in the pipeline and nearly complete.
ohhh. any idea when there will be a release. and will DUSB v2 be in that??
ACagliano wrote:
ohhh. any idea when there will be a release. and will DUSB v2 be in that??
DUSB v1.0 will be in it. Razz The only thing so far released is a (very) beta version of DUSB, which you guys tested. The one on my computer is much, much better but still far from perfect, which is why you guys don't have it yet.
KermMartian wrote:
ACagliano wrote:
ohhh. any idea when there will be a release. and will DUSB v2 be in that??
DUSB v1.0 will be in it. Razz The only thing so far released is a (very) beta version of DUSB, which you guys tested. The one on my computer is much, much better but still far from perfect, which is why you guys don't have it yet.


I'm a bit lost. The DUSB version we tested is an early beta. DoorsCS 7.2 will have a stable version. That right?

In any event, good luck and godspeed.
Correct, you tested Doors CS 7.2 Beta 1, which had an early implementation of Direct USB inside. That wasn't Direct USB 1.0, though; if there's anything that I'd call a 1.0 version of gCn DUSB, it will be whatever's inside the final stable Doors CS 7.2.
Calculator can not be completed for each individual three-way handshake, a three-way handshake when they do, they may players away.
I think he is a spam bot..
qazz42 wrote:
I think he is a spam bot..
He is, and has been deactivated. Thank you for your vigilance, Qazz.
you are welcome, I apologize for not reporting in the spam posts topic, but I was rushing and had to leave for the bus in about 1 minute x.x
Hey Kerm. I'm not sure if it's documented anywhere but I'm wondering what the starting and ending address of the CALCnet interrupt is. Also, is the Receive buffer completely assembled by the time the interrupt terminates?
ACagliano wrote:
Hey Kerm. I'm not sure if it's documented anywhere but I'm wondering what the starting and ending address of the CALCnet interrupt is. Also, is the Receive buffer completely assembled by the time the interrupt terminates?
The start of the interrupt code is documented here, plus the end address (based on its current size, which may change slightly in future versions):

http://dcs.cemetech.net/index.php/Interfacing_CALCnet2#Memory_Areas_to_Avoid

The receive buffer is indeed constructed by the time the interrupt ends, as long as a full frame was received properly.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement