TLDR: https://gitlab.com/taricorp/gcn

---

Calcnet and gCn haven't had much interest in the last few years, but I also know that the gCn metahub we've hosted here has been offline for a while. To keep things working for anybody who might want to play with it, I've taken it upon myself to try to bring all the tooling up to a modern standard.

The gCn hub and bridges source code was published at https://github.com/KermMartian/gCn, but it's pretty obviously not designed for use outside of the Cemetech server as things were set up around 2010: configuration is done by editing the source code and it's a Python 2 program (even using various obsolete syntax that was removed in Python 3).

I've forked the hub at https://gitlab.com/taricorp/gcn and have started doing some work on reimplementing the bridges (for connecting calcnet chat to IRC, allowing Gossamer to work again, ...), but since my current implementation is based entirely on reading the original code it needs some manual testing to check that I've actually understood the protocol correctly.

To test this, I've first needed to get the gcnclient running and talking to my server. I've found that to get the Windows client to see my calculator I need to set up the libusbK driver with Zadig, which is annoying because to make ticalc.link work it looks like I need to use WinUSB.

I also wish it were possible to update the client application and understand the protocol it uses, for instance to make a web-based version using WebUSB. Consider this a request to publish the source code (not unlike the next-most-recent post in this subforum).

Thus far I've verified that the gcnclient can connect to my hub, but I'm a little bit stuck fighting with ticalc.link to get a copy of CALCnet Chat! on my calculator to do some "live" testing against an actual calcnet application. I'll probably just faff with TI-Connect to get programs onto the calculator, but that's rather annoying.

---

Okay, so TI-Connect was more annoying than I expected but I got a copy of Chat! on the calculator and found that Merth had done some helpful work for me by providing a PC application that speaks the Chat! protocol so I was able to verify that my hub is able to pass broadcast messages without issue (since Chat! only uses broadcast messages), but haven't been able to test any other applications yet.

The code is terrible, from a C programmer who thought C++ was just C with extra bits, but ask and you shall receive: https://github.com/KermMartian/gCn/tree/master/gcnclient .

Let me know here or on Discord if you have any questions about the architecture of the client, the gCn system, the protocols, etc. that I can help with, as I probably have a fair amount of notes and internal documentation I haven't published.

Yay, thank you! This code looks to be of pretty similar quality to the rest of the gcn code, so I'm not troubled by it.

Based on a quick look it seems like the direct USB protocol is quite simple, so it shouldn't be difficult to reimplement at least a subset of the client in Python alongside the rest of my code.

I also did a little more poking at Chat! and found that it at least the demo application uses unicast frames (whereas it looks like the old IRC bridge always sent broadcast frames), which gives me confidence that my hub server works entirely as intended.

Possibly the real killer app to enable these days would be the FTP bridge, allowing you to download programs from the internet via a direct USB connection. With a client running in a web browser, that could then be done without any special software!

Just piping in here to mention, some of that ugly libusb code may be my fault. I do recall helping Kerm with something along those lines at some point while I was also poking at TiLP stuff around the same time.

Glad to see it being worked on more as it was always a cool project and glad to see it possibly making a comeback.

It was fairly easy to understand how the direct USB connection works in gcnclient, so I've now successfully used my own (Python) client and metahub implementations to get a real calculator talking to the CALCnet Chat! demo application.

My new client is about 300 lines of code, but probably half of that is just command line ergonomics. I'm not very interested in implementing the arduino or hidusb bridges because I don't have hardware to implement them, but having put together the framework to bridge a calculator into a gCn metahub it probably wouldn't be too hard to support other bridge hardware.

Current code is in https://gitlab.com/taricorp/gcn/-/merge_requests/3, where at the moment I want to do a little refactoring and add tests.

The vast majority of users use/used DirectUSB, so I think you get most of what modern users would want by sticking with just that.

I may be the single use case, but I would like to vouch for the Arduino bridge as it allowed for true wireless connectivity using the Particle Photon. But, even if it just ends up being USB, I am very happy to see that gCn is getting some TLC

These days I feel like you could do just as well with something like a Raspberry Pi Zero W and use the same USB implementation as works on a "real" PC; embedded solutions for both Wi-Fi and USB have gotten a lot better in the last ~15 years!

Yes, thinking of using this with the new libraries for ethernet.

Thinking in a little more detail about how a Raspberry Pi-based adapter could work, I realized it could be made into a very plug-and-play solution, both to set up the calculator to use gCn and to configure the Pi.

Software on the Pi could detect a calculator connecting, and silent link some utility programs across for setup; that would probably need to be a copy of DCS7 and a setup utility program. The setup utility could be used to configure the Pi (things like what Wi-Fi network(s) and virtual hub to connect to) by speaking CALCnet to a configuration broker running on the Pi that manages the gCn connection. That would mean a generic software build for the Pi could be used (no manual configuration needed), and it could be used simply as a dongle that attaches to a calculator.
The slightly tricky part would probably be in entering and leaving configuration mode, since the direct USB version of CALCnet doesn't do any framing (just dumping raw CALCnet frames over USB). The simplest solution might be to give the configuration interface a well-known CALCnet address and quietly redirecting packets sent to that address to the configuration tool instead of the global network.