CALCnet and globalCALCnet are each complex beasts. CALCnet 2.2 must handle all the problems of communicating between two devices, including synchronization, corruption protection and detection, delivery guarantees, and more, and solve the same problems for many devices, plus the additional problems of addressing, time-slicing the common medium, collision detection, and more. globalCALCnet, or gCn, must do all this while remaining effectively invisible to the calculators involved in the network, making it appear to the local calculators as if all the remote calculators are also local. As you can imagine, combining the two will be no mean feat, although the proposed method will helpfully eliminate some of the concerns.

If you have been following the globalCALCnet bridging projects at all, you'll know that both the Arduino and USBHID (previously "$10 Bridge") bridge types are powerful, but require extra hardware. Unfortunately, the majority of calculator coders and users out there lack some combination of motivation, skills, and funds to get, build, or set up such a device. To that end, there have been extensive requests for some way to connect TI-84+ and TI-84+ Silver Edition calculators to gCn using just their built-in miniUSB port and a USB cable. Because I have the unfortunate handicap of having difficulty not accepting a technical challenge, I will be attempting this project. Some important point:

What needs to change, calculator-side?
The principle of CALCnet is that programs don't need to worry about anything synchronous other than Cn2_Setup and Cn2_Setdown. They simply poll the send/receive flags every once in a while and check or set buffers as appropriate. CALCnet2.2 operates entirely over the serial or I/O port of the calculators, and using the USB port instead requires some significant complications. However, I want to change the Cn2.2 interrupt in Doors CS to handle USB cleanly (this will become Doors CS 7.2), namely:

1) Each time the Cn2.2 interrupt is triggered, check some flag or port to see if a USB cable is connected. Store this to a byte somewhere
2) Modify the Cn2.2 internal functions Cn22_ReadByte and Cn22_WriteByte to deal with USB if there's a USB cable connected
3) Is USB buffered? How does one construct incoming or outgoing packets? I've heard the term Virtual Packet tossed around a lot. I'd love some clarification on this.
4) All signs point to needing to jump into the TI-OS interrupt from the Cn2.2 interrupt if a USB cable is plugged in to allow it to handle USB stuff
5) Do I also need the TI-OS interrupt to detect the cable in the first place?

What needs to happen, host-side?
Clearly some wonderful USB manipulation. I understand that Shaun has written C# code to play with direct USB, so I hope I'll get a chance to stare at his code. I'm planning on writing the USB stuff in C++ for the sake of my own experiences, but I may take him up on his offer to write the host-side bits in C# if it doesn't go well. Special points for the gCnClient compared to the normal gCnClient:

1) Only one calculator will be connected to each gCnClient. Do I filter the frames on the host or the calculator? I probably still want calculator-side filtering anyway, so I'm thinking no host-side filtering.
2) Multiple gCnClients for multiple calculators on the same host computer? Somehow manage multiple calculators from the same gCnClient? Only allow one? Help me out here.

Thanks in advance for everyone's help and brainstorming on all of this.
Cool! I hope this works. Smile
KermMartian wrote:

1) Each time the Cn2.2 interrupt is triggered, check some flag or port to see if a USB cable is connected. Store this to a byte somewhere


I don't know the precise details off the top of my head, but there should be a couple of ports you can check to see if a USB mini-B cable is connected AND that it's powered (bit 1 of port 0x54 should be reset if powered; set when not powered or no cable).

KermMartian wrote:

3) Is USB buffered? How does one construct incoming or outgoing packets? I've heard the term Virtual Packet tossed around a lot. I'd love some clarification on this.


"Virtual packet" is a construct relating to the TI-OS direct USB link protocol, used by TI Connect and in calc<->calc transfers. You do not want this; it's a lot of unnecessary overhead.
Sending USB data is easy; it's simply a matter of buffering a chunk of data to the controller, and then telling the controller to send it (this would be repeated multiple times until all data is sent if trying to send more than the max packet size for a given endpoint -- since you are delegating all USB setup to the TI-OS, that is going to be 64 bytes). This is entirely handled by BCALL 50F2h -- it sends DE bytes at HL if I recall correctly (HL MUST point to RAM page 83h swapped into bank 1, so 4000h-7FFFh).
When the USB controller receives USB data, it triggers an interrupt. The TI-OS interrupt, when handling this particular event, will set 5,(iy+41h) to indicate data is ready. The TI-OS elsewhere (outside of the interrupt) is in a loop constantly checking this flag and, when set, will actually receive the data from the controller. It is not clear whether the controller has already received and buffered the data and is waiting for you to retrieve it, or your retrieving it is actually causing it to be received over the wire. It doesn't matter from our perspective; as soon as 5,(iy+41h) is set, receive the data to your own buffer. Don't put off handling this.

KermMartian wrote:

4) All signs point to needing to jump into the TI-OS interrupt from the Cn2.2 interrupt if a USB cable is plugged in to allow it to handle USB stuff
5) Do I also need the TI-OS interrupt to detect the cable in the first place?


Yes, you want to give control to the TI-OS whenever it's even remotely possible that USB communication could happen (meaning, you see that the cable is connected). The TI-OS interrupt will be responsible for handling the cable connection/disconnection events, powering up and down the USB controller, and handling the sending and receiving of USB data.
calc side:
1) Sounds good to me, except you might want to check ports 55 and 56 as well. IIRC, those are USB interrupt ports.
2) Sounds good as well, except I have no idea how you go about reading from the link port. It should work if you just check a "use_USB" flag or something.
3) Yeah, it can be buffered, as in you have a buffered. But in reality, you set everything up correctly, write all your data to port A0, and then write to the command port 91 to tell it you sent something. You read from A0 to read, and 8E tells the pipe number. See Virtual packet that Brandon talked about when he ninja'd this post.
4) If you handle it properly, and deal with interrupts, and acknowledge them, I don't believe the TIOS will even notice. I could be wrong here. I know that the driver doesn't like you to do something, and not do it completely. I've had the USB driver essentially stop working for a bit because I didn't read the data it was trying to send or something.
5) No, that can be done with the ports themselves.

Host-side:
1) No idea what you mean by filtering, so could you explain that?
2) Yes, or depending on what your using, you could most likely see a certain vender id and product id and claim it as your own basically. With a driver of some sort, you could have it claim automatically, but I don't think you'll have a problem with other things like TI-connect trying to take it over. I know the Mac side will start something called TI Connect X Manager or something, which prevents the calculator from being accessed by any other application.
I don't fully understand this, but I believe I have the general idea of it.
I'll send along my code to you, hopefully it'll be helpful. Jonimus looked at it and said it was helpful for theory but that libusbnet abstracts a bit.
Merthsoft, excellent, I look forward to it.

Graphmastur, your post has a few discrepancies with BrandonW's; would you mind clarifying the differences?

BrandonW, thanks a lot! Allow me to clarify a few things, if you don't mind. Do I have to swap RAM page 83h into Bank 1 myself before calling the bcall to send data, then swap it back, or does the TI-OS handle that itself? Does the receive buffer have to be on that same page?
Yes, you'll have copy the data you want to send to that RAM page yourself (however you want to go about that), and then call the BCALL.

There is no receive routine accessible by user programs/applications, so you'll have to copy the one from remote8x, which of course means it's received to wherever you want.

If you really want, you could duplicate what the send BCALL does so you don't have to mess with the extra RAM pages at all.
I like the idea of being able to send/receive directly to/from my buffers, but I'm also under the constraint that I need to use as little memory as possible. I guess my next step is to look at the disassemblies of the two BCALLs in question and see how extensive their functionality is.
KermMartian wrote:
Merthsoft, excellent, I look forward to it.

Graphmastur, your post has a few discrepancies with BrandonW's; would you mind clarifying the differences?

BrandonW, thanks a lot! Allow me to clarify a few things, if you don't mind. Do I have to swap RAM page 83h into Bank 1 myself before calling the bcall to send data, then swap it back, or does the TI-OS handle that itself? Does the receive buffer have to be on that same page?

Just assume brandonw is correct. Wink I know USB from a host side perspective a lot better than messing with ports that we don't fully understand.
That's fair, I'll keep that in mind. Smile Thanks for the clarification.
If you manage to get gCn to work through USB, this will be an even bigger revolution than the current gCn is by allowing online multiplayer calc gaming. Unfortunately, not everyone might be willing to setup the additional hardware required to use gCn, as you mentionned above, so it might limit gCn popularity, which is unfortunate due to its awesomeness, but now if you manage to allow it with only USB, its userbase size will explode. Shock

Good luck to you and whoever will help on this project. I hope it works out. If it does, would it also work on the TI-Nspire in 84+ mode, by the way?
DJ_O, if I go through the OS routines, as I'm completely planning on doing to save my own sanity, I see no particular reason why it wouldn't work on the Nspire, although we of course know how accurate the Nspire emulator is. Thanks for the words of encouragement, that's exactly my hope as well.
KermMartian wrote:
DJ_O, if I go through the OS routines, as I'm completely planning on doing to save my own sanity, I see no particular reason why it wouldn't work on the Nspire, although we of course know how accurate the Nspire emulator is. Thanks for the words of encouragement, that's exactly my hope as well.


Oh god, the NEW Doom game for the nspire, with gCn...

that.. would make any ordinary man have an instant heart attack ;D
Qazz42, well, keep in mind that someone would have to implement CALCnet/gCn in C for the Nspires to run in ARM mode; we're just talking about the 84+ emulator at the moment.
KermMartian wrote:
Qazz42, well, keep in mind that someone would have to implement CALCnet/gCn in C for the Nspires to run in ARM mode; we're just talking about the 84+ emulator at the moment.


I know, but I can't help but hope Razz
qazz42 wrote:
KermMartian wrote:
Qazz42, well, keep in mind that someone would have to implement CALCnet/gCn in C for the Nspires to run in ARM mode; we're just talking about the 84+ emulator at the moment.


I know, but I can't help but hope Razz
For sure. And I'm not saying it's by any means impossible, just that it hasn't yet been done.
KermMartian wrote:
DJ_O, if I go through the OS routines, as I'm completely planning on doing to save my own sanity, I see no particular reason why it wouldn't work on the Nspire, although we of course know how accurate the Nspire emulator is.
I also hope TI still plans to continue including a TI-84 Plus emulator in future OS updates. Shock
Anything's possible, with Popsicle (could.. not... resist)
DJ_O wrote:
KermMartian wrote:
DJ_O, if I go through the OS routines, as I'm completely planning on doing to save my own sanity, I see no particular reason why it wouldn't work on the Nspire, although we of course know how accurate the Nspire emulator is.
I also hope TI still plans to continue including a TI-84 Plus emulator in future OS updates. Shock
Shock Are there plans for them to not do so? That would be an absolute tragedy (and travesty)!
Well, the problem I am seeing is that the 84 keypads are really horrible, my nspire keypad works like a charm but the 84 one just refuses to work, and both have been switched in and out equally! I dont see the point of adding one in if it works for a few months and just flat out won't work afterwards Sad

eh, perhaps it is just bad luck perhaps :/
  
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
» Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 1 of 8
» 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