In theory, couldn't we just convert the sound data (say an mp3 file) to raw bytes, convert those raw bytes into letters and numbers or whatever, send that with the Send() command to usb headphones, and have it play sound? If this is even remotely possible, I would like to know and try it!

First of all those letter and numbers or whatever is called Hex
Second of all, the USB port just doesn't work the same as the I/O port on the 83 and 84.

I tried to explain this in my own words, but Iambian summed it up much better than I could


However (I just pulled this off of SAX) in ASM, you may be able to control the state of the D-Pin to simulate the I/O port.
(People please correct me if I'm just spitting out rubbish )

I meant the bytes as in bianary... I dont know why, hex is just better.


It would be best explained what im trying to do like this:

Say I have an mp3. The byte data is "10110010" (go with it). That corresponds to "2 12 5". Then you send "2 12 5" to usb headphones, it interprets the bytes as "10110010", and plays the music. There, overly simplified explanation. I was wondering if we can do that with the send() command, if not, control the usb in direct mode.


Considering the fact that I've done that before, not total trash at all. (if you're wondering, it worked, just not with sound, yet)

Sounds like you know more than I was giving you credit for!

It'd be a great idea if you could introduce yourself here!

Short answer: not possible. If you could twiddle data lines you could use some kind of entirely noncomplaint dongle to break it out as an analog signal.

A "real" USB audio output device will probably implement the audio device class, which the calculator's firmware doesn't know how to talk to. With a suitable calculator program (that directly interacts with the USB controller) you could communicate with an audio class device, but Send( will not work.

With some custom hardware (a device that pretends to be a calculator and speaks the calculator link protocol) you could use Send( for something like this, but given the complexity of building/programming such a device there's little point in this approach because it would require custom hardware.

I see.


So send() doesn't work. Is it really necessary to have an audio device class? If we simulate the I/O port, using a simple dongle would allow us to play music. Not so bad compared to what we had for the last calculators.

Sure, a kind of weird dongle would work- it's just very unlike what you originally proposed.

A possible hazard is that the D+ and D- lines on USB controllers are usually very sensitive, and you can easily damage the controller by overvolting it (putting +5V on the data lines). Since they're designed to be a complementary pair, you might only be able to twiddle one of the lines (and only get mono sound) and the drive strength may be very low (so you'd need an external amplifier).

Would it be possible to send things through the charging cable to, say, an Arduino, where data could be turned to sound and played?

I think at that point you may as well just make an arduino play music.

Sounds like i'm unqualified then... I don't think I could pull that off without knowing exactly what to do first. I've done it before on a ti-84+ usb port, i'd imagine they're basically the same. I don't remember what to do.
It would be nice if someone else tried it first, I don't want to destroy my calc...

Well we needed an amplifier on ti-84+ now didn't we? Also, mono sound isn't that bad...

For the last calculator, "all we had to do" was make/buy a simple adapter, and then you could just listen to music with normal headphones.

So? Its just one more step kinda. And you would be using an adapter for regular headphones, just a different one. Its called a dongle.

I could take 2 scrap wires lying around and make a 2.5 -> 3.5 "adapter".
With the CE, i am assuming you would need a micro controller or at least some TTL chips to convert the data from USB into sound.

I don't think you understand this fully. You twiddle one of the lines, get dongle (or make dongle) which is literally direct wires from usb to 3.5mm. Plug that in, load program, get music.

In fact, I feel you might not even need to twiddle any wires if we put the usb into direct with software. I doubt it will happen soon, but I feel its on the priority list right after "Push the limits" and "More images".

The downside to all of this is that it is HIGHLY unlikely it would work with usb headphones. Although, I read somewhere that a person had a setup on the NSpire where they had 2.5mm to 3.5mm, 3.5mm to usb, and usb speakers plugged in. It works fine apparently. If its consistent, that would mean just getting usb headphones, and plugging them in.

I don't think you understand, USB does not function like I/O. Although this may be possible, it just doesn't work the way you are suggesting.

Its not that simple, you dont just get to throw on a dongle and slap together a few send() commands. Trust me if that was all it took, people would have done it long ago. It is possible to use a TI-Innovator Hub to do this in basic, but thats garbage and nobody has one and its almost cheating and it costs so much you will have to sell a kidney or two on the black market.
Any other option is asm either directly or through an arduino (which I think is also a bit cheat-y). Progress is slowly creeping along regarding the issue of sending and recieving anything at all (including music of course) through usb. As for the projects with a ti-nspire series, those were actually wires soldered onto the gpio pins on the dock connector on the bottom of the calc. (link)

Look, at this point I have given up on send() commands. Im talking about what the end user needs. I understand there is a huge amount of work involved for developing this, but I do know what im talking about. Yes the nspire used soldiering, but I was talking about the cords. If a usb speaker works instead of 3.5mm speakers, it might work elsewhere too.


As for that, simulating the I/O port is possible. Its a matter how we work with it. It would require a lot of work to complete, but it is indeed possible. Simulating any hardware is a tricky task, especially on a calculator designed for coloring graphs.

The point is, it will happen. There will be people who come along and figure it out. If we all focused on sending or receiving data, you could do nearly anything a raspberry pi or arduino could. For gods sake, a man got INTERNET on a ti-84+. There is potential, and we must work to achieve it.

So please, work with me here, and accept some ideas, whether they work or not, you must try.

If i remember correctly, the internet on the calc was done by having an either an arduino or a "photon spark" (?) connect to the internet, and then act as a proxy for the calculator. Thus connecting an arduino to a calc via USB is already possible (at least on the ti84+), and thus you could send data (mp3 or midi) to the arduino, telling it to generate the sound, but you wont be able to generate sound on the calc itself, unless somehow there is a way to manually toggle the data lines on the USB, which i dont think is possible.

USB controllers provide no way to arbitrarily toggle the D+ and D- lines on USB ports, as indicated earlier by Tari.

c4ooo: correct. On 83+/84+-class calculators with monochrome screens, "Internet on the 84+" was (originally) done through the following setup - I bought an Arduino for testing it:

Calculator with 2.5mm stereo proprietary jack running a program to implement a custom protocol called CALCnet (with Listen Before Talk, calculator ID and other capabilities which make it suitable for unicast, multicast and broadcast communication between more than two calculators - IIRC Kerm tested it with at least 9 calculators)
^
|
v
Arduino running custom firmware to speak the aforementioned custom protocol on one side, serial USB communication on the other side
^
|
v
A program running on the computer, communicating with the Arduino on the one side and through the Internet on the other side with the globalCALCnet ("gCn") gateway running on Cemetech.
^
|
v
(IIRC, it was technically split from the gCn gateway, but I might misremember) the Internet gateway running on Cemetech to access (some of) the general Internet.

On USB-capable models, you can do without the Arduino, but you'll lose the direct multicast & broadcast capabilities because USB uses master/slave communication.

Years before TI calculators entered the USB era, connecting calculators from the TI-68k series to the Internet, using their 2.5mm stereo proprietary jack port, going through a GrayLink cable and a gateway running on the computer, was done by Samir Ribic: http://www.ticalc.org/archives/news/articles/4/43/43965.html .