Use an FPGA to link your computer with your TI calculator. Faster than TI cables, MIT license.

It is written in verilog and does not use vendor libraries, therefore it should work on pretty much any dev board that can do 3.3v. I've developed this with an iCEstick and a TinyFPGA BX using the yosys+nextpnr stack.

It's been tested on ti89 and v200 as they're the ones I have. It seems no less reliable than the grey and silver cables I have, and dramatically faster.

https://github.com/rvalles/dbus_ti_link_uart_verilog

Please give it a try if you're able.

Interesting comparison to the AVR (arduino)-based Silverlink clone Geekboy made a while ago. Neat choice to use the graylink protocol, which I've never seen used before (it's too old for me!); I'd never even considered that it could be implemented with modern hardware, but it makes perfect sense and isn't very complex. Sadly I own a TinyFPGA Bx but it's not in a convenient location so I can't try it out myself.


Why the commentary on reliable dbus speeds? Since the protocol has built-in flow control why does it matter what speed you clock the interface to the calculator at? Or does that affect timeouts and maybe it should be exposed as a more obvious configuration knob (or even just increased to be universally reliable while sacrificing a little performance)?


While I've done enough FPGA work that I could make this work, I doubt many others have. Do you have any plans to write more accessible documentation with things like links to hardware and how to connect it all up with prebuilt bitstreams to make it easier to get started?


It's rather unfortunate that you need to patch libticables to work with this- though the main change is just not attempting to query the port options with TIOCGSERIAL, right? It looks to me like turning on flow control and increasing the baud rate is just for performance since it can work without flow control at lower speeds.
It seems like that could (and should!) be upstreamable maybe with some configuration. Though some basic software that only speaks the graylink protocol as a TiLP alternative like you allude to might be reasonable (but comprehensive support for the PC file formats might be a large enough task to scupper the endeavour..).

---

You now have me wondering how cheap an open source USB graylink based on this sort of principle (optionally not on an FPGA, due to cost) could be made. Unfortunately I doubt there's enough interest in them to be worth doing a high-quality design and manufacturing it, which kind of makes it pointless.

I used a similar project to talk with during for early development, before I wired it to the actual calculator.

I don't think it's the same one, it was found here: https://github.com/jw0k/serial2ti83/blob/master/serial2ti83.ino



When monitoring the wires with a logic analyzer, I found the ti89 i/o gets stuck if I send a bit immediately after the calculator releases ACK on the opposite wire.

Some code in the calculator is polling to see the event where I release the wire after I see the ACK has been released, but doesn't poll fast enough and misses it. Therefore it thinks I'm still holding that wire from before the event.

I found lowering the frequency of the clock in the FPGA that runs the dbus itself solves this issue, without actually affecting performance. It's more than fast enough that way. Most of the communication time, the bus is idle and the fpga is waiting for the calculator to respond in some way. Basically, the calculator CPU is the bottleneck here.

I am considering just lowering the clock I run the fpga logic to ~4MHz instead of the highest value I tested, because that should have negligible influence in the bitrate achieved and provide a safety margin.



For now I'd be happy enough if someone who has a FPGA devboard and is familiar with it is able to test this. I don't know if FPGA dev boards are the friendliest thing for a not-very-technical end user to be directed at.



Regarding TiLP/libticables, I'm certainly not a fan. It's GUI-only and excessively rigid, with serial port selection being a #1-#4 droplist instead of the device name. It's also not the easiest to understand GUI.

As I am more or less happy with the state of this project, I will likely write something to talk without the calculator without using any of that code next. It will support connection options other than my verilog thing.



I believe I could make it work, with flow control on the uart, with an LP384. I'd need to shave the design a little as it doesn't currently fit that, but it should be possible. These don't have memory blocks at all, so the buffers would have to be tiny and logic-based.

A more sane option would be to grab an icesugar from aliexpress... they are around 25€ and do use the iCE40 UP5K which should be plenty for this. I don't have one yet but I hopefully will soon.

For non-fpga based, there's the stm32 black pills at around $1, and some attiny-based micro development boards that are just a tiny pcb with the USB contacts printed in one side and 5 or so i/o pin headers in the other, which sell at around $0.5.

And you're right in that it would indeed be absolutely pointless, even if very possible, to create a board specifically for the task.

I saw this topic through the POTY one.

Interesting work indeed. With the decreasing cost of custom hardware, making SilverLink replacements is getting easier


Definitely. In fact, a better solution for the first hunk about TIOCGSERIAL is in libticables nowadays, after an independent report. And how to implement the two other changes is described below.


* well, strictly speaking, TILP has a CLI, though it's very limited. "For practical purposes, it's GUI-only" is a correct, fact-based statement, though ^^
* the libraries are used by CLI/TUI programs: titools, and libticalcs' own test_ticalcs_2, which has decent scriptability nowadays, especially on the experimental2 branch.


In the GUI, indeed.

You don't seem to want a GUI, in which case, a little-known solution has been supposed to allow that since early 2015: ticables_cable_set_device(), which delegates to gry_set_device() in the file you've patched, and has an effect in the function which consumes the device name you've patched
As for the two other changes you're making:
* on the libticables side, the line speed changes and the flow control enablement would be amenable to the same kind of technical solution, setters called between the creation of the CableHandle and the actual usage of the CableHandle;
* on the TILP side, the information about the device, the line speed changes and the flow control enablement need to be stored in the config file. Adding the GUI I never wrote to control the device name and the new functionality would obviously be icing on the cake.


By cutting lots of corners, making communication work with 1-2 cables, a single family of file formats and a small subset of a single communication protocol (e.g. limited to file transfer) is easy enough - as a matter of fact, it has already been done multiple times.
However, basically all of the pieces in libti* need to be there in a replacement thereof, otherwise some statistically significant use case suffers. libnspire's functionality is especially narrow (basically, only file transfer for the Nspire family, and not reasonably reliably so, for years). Rewriting the full functionality of libti* - character conversion, two-way computer files handling, the subset of cables relevant to the modern world, the 3 sets of protocols used by TI calculators + the libticalcs ROM dumping one, all operations supported by calculators - represents a huge amount of work, and is the main reason why nobody has taken on that task, with good reason.

Not to say that the libs are perfect, obviously, and I've tried to do my part in improving them in multiple areas since 2009.

Very good news.



Excellent. I also heard from you on IRC that the situation will improve soon about custom grey cables (such as my FPGA thing).

Do note something will probably need to be done in the GUI regarding transfer progress. The progress bars and calculations of transfer rate go nuts with the never-seen-before speed of my FPGA implementation.



These days I do most of my testing with link68 (a newish python implementation with a permissive license). I will be happy to use TILP frequently again once the new stuff is wired

On my FPGA "grey cable", the next planned points are to support ECP5 and GW1N (this one has devboards that cost less than $10, and specs sound sufficient), and to try it on my z80 calc (TI-86), which as far as I can tell presents 5V, so it's pending me getting some bidirectional voltage shifters.

I'm particularly curious about how fast transfers will be with the z80; it will likely be much slower than the TI-89, but still considerably faster than with traditional cables

The TI-86 is fine talking to 3.3V devices like the newer calcs are assuming they can handle the 5V input. So as long as the FPGA boards are tolerant of the 5V I believe it shouldn't be too big of a deal.

FPGAs with i/o banks that do 5v do exist, but are uncommon. I'm not aware of the open stack supporting any. Unfortunately, we're talking mostly about old FPGAs and a bunch of CPLDs.

iCE40 definitely are not 5v-tolerant and will fry if exposed. I'm hopeful bidirectional 5v wil get me there w/o introducing too much latency to slow my benchmarks down.

Thanks. Well, IME, the calculations of transfer rate have always been nuts since before I became the maintainer, but I worked on a wide range of other more important functional and non-functional improvements.


That one isn't bad work, though I've never looked thoroughly at the source code.
FWIW, making a full-featured, permissively licensed implementation of the TI link transfer protocols is impossible. The linkguide is intentionally unmaintained: the reference is the GPL'ed libti* source code.

This project is absolutely brilliant! I was considering trying to work out a TI DBus graph link implementation in hardware and was glad I found this existing work because this project handles more than what I was already thinking of including hardware flow control, ring FIFO, timeouts!


Perhaps a few years late, but I happen to have an iCEstick around and after fighting with yosys/nextpnr versions a bit, was able to successfully get transfer with TI-89 and link68, replicating your work here. For some reason, iCEstick prices have more than quadrupled, so I no longer recommend it. Glad to see you have several other supported FPGA dev boards. I'm working on adding the Sipeed Tang Nano and tinyVision.ai pico-ice just because I have them on hand and yosys supports them. I will create a PR once I test that out.


I hope I'm not too late to ask, but I was wondering about the pin assignment choices. In the repo config, Tip is 60 and Ring is 61, but there is a sleeve pin assigned to 62. The GND pin is right next to 62, so could Tip=61, Ring=62, Sleeve=GND? I didn't have either breakout headers installed, so I ended up moving the assignment to the PMod header, Tip=80 (PIO1_04 / PMOD pin 3), Ring=81 (PIO1_05 / PMOD pin 4) as depicted below. This works the same as the default pin selection.


Agree, this is definitely going to be a problem for using this with TI-83, TI-85, TI-86. Using an NPN transistor and Schottky diode for each of the nets, we can implement a suitable level shifter to work with 5V calculators. This works without a 5V reference voltage since the bus is pulled high on each end and driven low to communicate. Below diagram is a breadboard version of this with the wiring I'm using to a calculator 2.5mm audio cable.


To make this more convenient, and as a general purpose TI graph link level shifter, I'm looking at designing a cheap PCB with these components. I'm leaning towards using the 6-pin PMod connector as an interface since that is common on the iCEstick and some other FPGA boards such as the Basys and pico-ice. Currently, just uses the power and 2 inputs with the level shifting passives, but may add in the LC low-pass filters and some status LEDs. Any other good ideas or should I just go all in with a minimal FPGA and FTDI chip to make this an all-in-one setup?

I don't think it would be very useful to make an all-in-one device due to the higher hardware complexity. Unless you were able to provide them for sale at a low price, it would probably be more useful to most people to be able to take advantage of any other board with PMOD connector(s), so prospective users could use any host board they can get (or already have).

I remember ordering something else and seeing the iCEStick on sale at around 20 GBP. That's the only reason I considered buying it. After confirming it was "iCEStorm compatible", I added it to my order. My first FPGA, which I still have with me; ICEStick got me into FPGAs, which I wasn't trying to do.

It's far less relevant today, with more chip families supported by yosys/nextpnr and a range of open source or otherwise cheap development boards available.

I have a Tang Nano 9K as well, and a ULX3S (ECP5) but never got around adding them. I will definitely test these boards if you get them working



I use a short 3.5" to 2.5" cable, and got a bunch of 3.5 TRRS jack adapters, sourced from china. They have tip, sleeve 1, sleeve 2, gnd. Thus the electrically horrible workaround, because I wanted to just connect the 4pin adapter to the iCEstick.



PMod is nice. Works with most FPGA development boards, and simplifies the wiring to just the PMod.

Do the shown gerber and schematic not match? (gerber has no NC pins for PMod)

Thanks for the guidance. I think I agree with your assessment so will continue to pursue the PMod board. I've decided to add the LC high-pass filter and changed to a dual diode package. I'll update this thread with a schematic and PCB layout when I've settled on the design.


I think that's roughly what I remember paying for my iCEstick years ago ≈ 25$ USD. Now they are selling for 125$ USD from all sellers.


Unfortunately, the Tang Nano FPGA boards don't wire in flow control, but otherwise seems doable. I'll update here.


Thanks for the explanation, I understand now. I didn't realize it was TRRS jack, but I see that in your pictures now taking a closer look.


Good catch, thanks for calling this out. I think I have this backwards on the layout. The PMod connector has 6 pins and I'm proposing to use pins 3,4,5,6 for tip,ring,gnd,vcc. Pins 1,2 (top two on schematic) are NC, but the PMod spec starts numbering these from the top in this orientation and I started from the bottom. I would still work with the 6-pin variant just flipping it upside down, but that was not my intent! I'll correct this.

In future updates, I may move discussion of the Pmod board to it's own thread to keep this topic about verilog, but quick update on progress for the Pmod graph link board. Edit: I am moving part list and discussion to separate Pmod breakout board for TI graph link and voltage translation topic to keep this thread about Verilog and interfacing with various FPGA dev boards.

Below is the updated schematic, PCB, and rendering. I corrected the Pmod pin order, added the LC filters on both nets, and updated the 2.5mm audio jack footprint. I'm looking to make the LC filters and the debug header is optional. In order to make the inductor optional, I'll either need to make a bridge with jumper or start with a short that can easily be manually cut to install the inductor.

Bringing some updates to this verilog thread. I have boards and parts for Pmod breakout board for TI graph link and voltage translation Rev A protoypes and tested with two different FPGA boards: iCEstick and pico-ice. Both are working well. If anyone in this thread wants a couple Pmod prototype boards, just DM me and I'll ship you some, either assembled or solder your own.

I created a PR for the pico-ice based on my testing. Since it is derived from the iCE line of FPGAs, porting used the same toolchain. The other half of it uses Raspberry Pi RP2040 which implements the USB UART and programmer side of things. This FW doesn't support flow control by default, but is hackable so maybe there are some creative ways to use it for this.

I'm still working on the Tang Nano line of FPGA boards. These also can use yosys, but the nextpnr tools use very different file formats and commands, so it is requiring some abstraction in the makefiles. I'll likely create a PR draft with my proposals for feedback.

I have so far been using link68 or manually testing commands, but also struggling to get TiCL gray link patches working under Linux with the iCEstick

Link68 is great.

Re: TiLP, at the time, I just wanted to get it working and focus on the hardware part, thus the patches I made are ugly; definitely not the best approach for upstream merging.

I remember concluding after a look at the code that doing it properly would have been too involved.

Are you talking about the likes of https://gist.github.com/rvalles/f937889712d24ac6824f1358c936b3e2 ?

Yes. That was enough to get going, fortunately.

Yeah, it's a permanently pinned tab in my browser, but I haven't integrated that in a proper API.

I would implement it as a generic serial port support, where you can pick the local device, speed and hw handshake vs no handshake.

This would cover a range of solutions, not just this FPGA one. There are e.g. arduino sketches that turn the protocol into serial, and these run in a myriad of hardware, as arduino core is ported to so many families of microcontrollers. The only common point is that they look like a serial port at the computer they're attached to.