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