Over June 13th and 14th, I am releasing three key pieces of Cemetech software that have finally reached fruition after about two years of development. In order of release, the three programs are Doors CS 7.2 Beta 3, gCnClient 2.0, and Sandpaper 1.0. Doors CS 7.2 Beta 3 is final beta release of Doors CS 7.2, which brings new networking features to the popular calculator shell. gCnClient 2.0 is a final, stable version of the Windows/Linux/Mac OS software for connecting calculators to the internet. Sandpaper 1.0 is a completed FTP server and client for transferring files across a room or around the world.

June Software Trifecta:
Part 1: Doors CS 7.2 Beta 3
Part 2: gCnClient v2.0
Part 3: Sandpaper v1.0

This second article in the trifecta introduces the long-suffering version 2.0 of the globalCALCnet client (gCnClient), two and a third years after version 1.0. While Doors CS 7.2 beta 3 contains everything you need to network calculators together locally, you can't easily connect your calculator to the internet or to other calculators dozens or thousands of miles away. That's where globalCALCnet comes in. First, gCn allows you to connect CALCnet networks together, making calculators that are far apart think they are locally networked. Secondly, gCn lets non-calculator services like HTTP, IRC, and FTP be easily connected to CALCnet networks. This means that you can browse the internet with Gossamer, chat on IRC with CALCnet Chat!, or browse the ticalc.org archives with Sandpaper, all directly from your calculator.

To connect your calculator to gCn, you need a computer to mediate between gCn and CALCnet (although that may soon change). On that computer, you run the gCnClient software, which you can download below. gCnClient 2.0 lets you use a mini-USB cable with a single TI-84+/SE, or an Arduino or AVR as a bridge to a large network of TI-83+/SE and TI-84+/SE calculators. This version adds the mini-USB ("direct USB") support, as well as greatly improving the stability of the entire client.

If you want to connect your calculator to the internet, or to friends' calculators across the internet, grab the download below! Be sure to read the included readme for a quick guide to setting it up, or the comprehensive PDF for a full description of how gCn works. Don't hesitate to post up any bug reports or comments and questions you might have about globalCALCnet. Oh, and enjoy the video below of me explaining the high-level view of how gCn works.

Download:
globalCALCnet (gCn) Client v2.0

Great work!

Mac users, I've compiled against the 10.8 Mountain Lion SDK specifically, so let me know if you have problems. I'd prefer not to have to download a large older SDK, but I will if necessary. Most computers that can run Snow Leopard (or even Leopard) should be able to run Mountain Lion, so the $20 may be worth an upgrade, even if you don't have it yet.
From my testing, the libusb v0.1.4 Mac OS X client may not work reliably. Do we have any Mac OS X users with a TI-84+/SE and a mini-USB cable who might be interested in seeing how well the Mac OS X build of the gCnClient works for them?
I'm trying on archlinux, and it keeps dis-and reconnecting

Code:
sorunome-laptop% ./gcnclient_ubuntu -n FTPHub -l Sorunome -d d
Info: Using default server host gcnhub.cemetech.net
Info: Using default port 4295
Direct USB connection created successfully.
Resolved hostname.
Wrote 19 bytes to socket (join msg)
Direct USB device disconnected!
Calculator successfully reconnected.
Direct USB device disconnected!
Calculator successfully reconnected.
Received message of length 28 from server.
Direct USB device disconnected!
Calculator successfully reconnected.
Direct USB device disconnected!
Calculator successfully reconnected.
Direct USB device disconnected!
Someone in the channel (Jonimus or benryves?) mentioned that some versions of libusb have that problem. Does anyone know what version we should be using to avoid it?
elfprince13 wrote:
Someone in the channel (Jonimus or benryves?) mentioned that some versions of libusb have that problem. Does anyone know what version we should be using to avoid it?
Not a clue, I'm afraid. Sorunome, can you compare the libusb version you're using on Arch Linux to the one that works on whatever else you use?
i got all the lib32-libusb thingies from the aur as it needs the 32bit ones, it didn't find all the libusb thingies from the official repos which I installed.
Kerm, would you mind compiling the client for ARM so that I can run it on my Raspberry Pi? It's just that that would be somewhat awesome Very Happy
Is the distro you're using on your RPi using the hard-float ABI (in Debian parlance, "armhf") or the soft-float ABI (Debian: "armel") ?
I'm using raspbian, but the problem is that the client isn't compiled for ARM prozessors.
Sorunome wrote:
I'm using raspbian, but the problem is that the client isn't compiled for ARM prozessors.
Yes, but the question that Lionel asked is relevant to me deciding which architecture to compile for. Smile If I can get you to agree not to redistribute or reuse the source without permission, I'd be happy to send along the gCnClient source so you can build it yourself, thus saving us figuring out what exact architecture you have and saving me compiling a cross-compiler.
KermMartian wrote:
Sorunome wrote:
I'm using raspbian, but the problem is that the client isn't compiled for ARM prozessors.
Yes, but the question that Lionel asked is relevant to me deciding which architecture to compile for. Smile If I can get you to agree not to redistribute or reuse the source without permission, I'd be happy to send along the gCnClient source so you can build it yourself, thus saving us figuring out what exact architecture you have and saving me compiling a cross-compiler.
Oh, ok. I defenetley agree on not distributing or re-using the source in any way. All I would distribute is the compiled executable. And i'm always glad to help out Smile
Also, my email is mail [at] sorunome [dot] de
FWIW, there are at least two usable ways to avoid building a cross-compiler yourself, Kerm Smile

Both rely on setting up a small chroot of the target architecture, installing additional packages there through the distro's packaging system, whether when creating the chroot or later through entering the chroot and installing there.
Under Debian, that amounts to a small shell script, which contains mainly an invocation of debootstrap (you can add extra packages directly if you wish), `ln /usr/bin/qemu-arm-static /target_of_chroot/usr/bin` (or cp if you're on a different partition), and the same invocation of debootstrap a second time, so that the job which failed due to the lack of qemu-arm-static in the target system completes.

From that base, you can:
* point an existing, pre-built cross-compiler (from Linaro, CodeSourcery, etc.) to the chroot, through -I, -L, etc. options;
* chroot into the target environment and compile directly from there, relying on QEMU doing the emulation. That's slow (but your program is not huge), and for many programs, it works pretty well Smile

Besides ARM, several other architectures, such as Sparc, Power and MIPS, lend themselves to the latter solution. QEMU is complete and stable enough for those architectures.
That's quite clever, Lionel; thanks for sharing. I'll definitely have to remember that the next time I want to cross-compile something for an architecture like ARM. At any rate, Sorunome agreed to my terms, so I'll send along the code and see how his recompiled version works. Sorunome, you need to make sure you have libusb 0.1 available.
chroot's for cross-compilation are the bomb. They're also great for testing 32-bit compiles on a 64-bit Linux (and making sure you can link against the correct 32-bit libraries).
  
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 1 of 1
» 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