You are probably going to want to play 8 bit music, so I'll go with that. You need to turn the link port on an off for varying amounts for each different byte. So say you have 257 units to work with. For byte 0 it would be 1 off and 256 on. Byte 1 would be 2 off and 255 on. Byte 2 would be 3 off and 254 on. And it continues on...

But to do this accurately and very fast, (<200 t-states of switching code if you want good quality), you need to sacrifice space for speed. This means making a huge table of code for every single possible byte. The way you do this can vary, but you basically have to have dedicated code if you want quality.

Also, using this technique, you have to have music of at least 20KHz sample rate. Any lower and those with really good hearing will be in pain.


That's not really pseudo code, but that's how I do it.

Those are wav files. I mean 8-bit wav files. Not midi's. I have no idea how those work.

The instructions are for what you do once you have read the header and are going to play music for real.

I wonder if the source of this could be useful? http://www.ticalc.org/archives/files/fileinfo/176/17685.html

Yeah I wasn't sure how optimized it was, though, since it was made several years ago, before many today's tricks were discovered. I just rememebered using that back then. It did 11 KHz 8 bit music, if I remember. A 3 second audio file is 20 KB on-calc, though...

For units, this is basically the most amount of t-states that you can fit within your time constraints. So a bit of math: 15,800,000 t-states / 22500 hz = 702 t-states per byte. Now, we need 257 units, but to be safe around the edges (1 unit is usually impossible) we'll call it 260 units. So your options for units are either 1 or 2 t-states. 1 t-state will give you 442 t-states for note switching but low volume. With cheap headphones, it probably won't be audible. 2 t-states is what I use and that gives you 182 t-states to switch. That's plenty of time for optimization if space is an issue, or time for compression .

So I would recommend that you use 2 t-states as your unit of time. This is so small that you can see why you need dedicated code. And you correctly understood what I said the first time.

Oh, and I used 15.8 MHz as the calculator speed because that's the average speed that I have found in calcs. I have seen some as slow as 14.8 and as fast as 16.2.

You could port MTV Music Generator to the TI-Nspire.

Well, TI-Nspire plus TI-84+ keypad gives me 90 MHz and an I/O port to work with.
At 90 MHz, with a music frequency of 44100 Hz, I have 2040.8 t-states per byte to work with.  With 257 units, we have 1783 t-states at one t-state per byte.  At 4 t-states per byte, we get 1012 t-states per byte.  6 t-states per byte leaves us 498 t-states per byte.  Shouldn't be a huge problem
(I just guessed at your calculations.  Care to elaborate how you got these numbers?)
And as for decoding the MP3, I would just do it in real time to save the user the issue of waiting.