I can't test it today, but I will definitely test it tomorrow.

Working out pretty well on my end. Not without it's flaws but I believe all have been mentioned. Thank you KermM, Jonimus, Shaun/Merth, and all who contributed.

I'm headed to sleep now, thank you very much to everyone who is helping test! I'd imagine that the main problem is stemming from one fundamental difference between I/O and USB. With I/O CALCnet, a calculator can simply choose to not receive frames that it doesn't have the resources to deal with yet (ie, the receive buffer is full). The sender will just keep trying until the receiver acknowledges the incoming frame with a checksum. With USB, though, ignoring data is much less clean. I can only imagine that something is getting disturbed, either the calculator is getting confused when USB data is ignored, or perhaps the client PC-side is dropping frames that time out, which it shouldn't. Any ideas? Jonimus and the other PC side experts, any thoughts?

Well I found one thing that may help with getting the connection to work the first time around. Haveing the hub drop packets until a calc has sent a proper calcnet broadcast. It shouldn't hurt to do this since the calc will be ignoring these packets anyway. Right now it seems as soon as there has been one timeout in usb_bulk_write they continue to happen. Once in a while it will recover from them but it seems to have a better chance of recovering if the timeout occurred after the calcnet program was started.

I also started to look into some code to detect cable disconnects sooner which I can share with you in the morn as well as a few other changes I started to make.

As to the other issues, I haven't had a chance to dig into them much but I will when I get a chance.

Well, we actually do want it to be able to time out when the calc-side interrupt is unable to handle a new packet, but it shouldn't turn into an infinite timeout. I actually need to test with the two classical types of gCn bridge to make sure they still work and that I haven't done any overall breaking. The other thing that I don't like is that it doesn't seem to work to start the gCnClient program once CALCnet2.2 is already active, for some reason, which I definitely don't want to be the case.

Would gCn work on a TI-86?

CALCnet (and gCn through an Arduino / HID bridge) could work, unless the processor is clocked definitely too low (but I don't think so).

I think the 86 has a 6Mhz processor, like the 83+.

That's what it seemed to me, thanks for the confirmation

I know 83+ have different connection than 84+, but is there a hope that is possible ?

(or a 84+ could be like a modem ?)

@kinder That's what the Arduino/$10 bridge is for.

As Souvik said, that's what the Arduino bridge and the $10 Bridge are for! This is to connect TI-84+/SE calculators over USB without needing any extra hardware. Elfprince, Merth, and I are all together IRL now, and we're going to work on Direct USB!

You'd better. >

But seriously in response to your response to my earlier comment....

I think the calc is having issues recovering from write timeouts. Maybe you are not handling them properly, I'm not sure. In any case its better if your code is handling all of them so you have a better idea of the hardware state, hence why I was saying you should just drop packets until the calc has enumerated itself in order to not have the OS do things you don't want it to, at least in the DUSB case. This would also help with the calc once in a while freezing while trying to open DCS and then said calcnet program.

OK, that would certainly make a lot of sense, and I'll add that to the gCnClient in the morning. And I just asked Merth to help me remember. However, this does not fix the issue of why we can't plug in the cable while CALCnet2.2 is running (assuming that fails for you guys as well). And I agree that I need a better way of ignoring the incoming USB than just not handling it. Perhaps I could not run the interrupt again until the receive buffer got emptied? But I wouldn't want some kind of potential receive/send deadlock to occur. Argh.

I think that issue is unsolveable, you need the OS to handle descriptor requests and the like which it doesn't seem to do while your code is running. I think that the current setup for starting up the client is most likely the best way to do it sadly.

Psh, I refuse to accept defeat that easily. I use detection of VUSB+ to decide when to start running the OS interrupt and thus to let the OS start USB initialization. I can only assume that something's going wrong in that process? Perhaps BrandonW could advise me on that issue.

I have a question: might you make the connecter just an exe prog? I cant run batch files @ school

thanks in advance!

It is an exe file, the batch file just automatically adds the arguments to the exe

And if your school allows you to run EXEs but not BATs, it's retarded.

Luckly for me, they do not let you install stuff, but you can run .exe and .bat