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.

Quote:
These calculators work reliably with dbus running at 8MHz.

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)?

Quote:
Be careful with FPGA i/o pin tolerance. TI dbus is maintained at 3.3v.
Edit Makefile to uncomment or add fpga board.
Edit board PCF to suit board board and preference.

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?

Quote:
Patch grey cable for the uart device/rate/hwflow.

Like this: https://gist.github.com/rvalles/f937889712d24ac6824f1358c936b3e2

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.
Tari wrote:


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

Quote:

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)?


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.

Quote:
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?


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.

Quote:
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..).


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.

Quote:
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 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 Smile

Tari wrote:
It seems like that could (and should!) be upstreamable maybe with some configuration.

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.

rv68k wrote:
Regarding TiLP/libticables, I'm certainly not a fan. It's GUI-only

* 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.

rv68k wrote:
and excessively rigid, with serial port selection being a #1-#4 droplist

In the GUI, indeed.
rv68k wrote:
instead of the device name.

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 Smile
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.

rv68k wrote:
I will likely write something to talk with the calculator without using any of that code next. It will support connection options other than my verilog thing.

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.
Lionel Debroux wrote:

* 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.


Very good news.

Lionel Debroux wrote:

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 Smile


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. Smile

Lionel Debroux wrote:

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.


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 Smile

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 Smile
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.
TheStorm wrote:
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.
Quote:
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. Smile

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.

Quote:
These days I do most of my testing with link68 (a newish python implementation with a permissive license).

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.
  
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