A lot of frustration has occurred since my last post. Although no one really cares, here is what happened.

1. I got 22khz working.
2. Ti-connect refused to send the 1250k app via usb.
3. After 30 minutes via silverlink, my batteries died.
4. I got compression with LZ77 working, (uses past 16k as a reference for copying)
5. .wav files compress .5% via LZ77.
6. New compression algorithm cuts 5%-10%
7. New batteries, sent via silverlink in 30 min, invalid
8. Installed tilp, spent lots of time working it out.
9. Tilp crashes on 1250k but sends smaller ones.
10. Those smaller ones are invalid.
11. Got wabbitsign instead of wappsign and signing works.
12. Tilp stops working all together.
13. Reinstall Ti-Connect, and send the new 1 minute sample.

Here is the video I promised.


After my complete failure with LZ77, I looked at the hex of the .wav files to see what I could do. I noticed that there were lots of numbers in the $70's and $80's. So my compressor writes numbers between 79 and 87 as nibbles to save space. So instead of 79 7A 7B 7C 7D 7E 7F 80 81 82. It writes 00 12 34 56 78 9A 00. The 00's are flags telling when compression starts and stops. This works decently, especially with quiet sections.

If anyone has any suggestions to compression techniques I'd love to hear them. The only problem is that they have to be able to get the next byte in exactly 108 t-states. But I do have a whole 16k ram page to work with.

What about Huffman coding?  I remember it was used for a previous sound player... although i dont remember which.  It seems to be the type which would help with this type of data tho.

Did you forget to restore IY?

Cool stuff! Quality is quite good too. What size was the sample heard in the video?

Thank you for your effort, to bring "true sound" to new TI-84+SEs.

Compression is really useful to something like this.
You are really on the limit of the z80 CPU at 15MHz.

Sure, I'll send it to you when I'm done. The only problem is that you have only and exactly 182 t-states to get a byte. I'm not exactly sure how you'd do that with usb. But if you pull it off, that'd be nice.

Actually, the playing part is finished, compression's all I'm working on. You'll have to modify it a bit to fit your needs, but here's how it works. You have to figure out exactly how many t-states you have to work with. You do this by taking your processor speed and dividing it by your sample frequency. Mine is 15,800,000 / 22,050 = 716 t-states. Then you have to subtract the length of the subroutine, which is 516 delay + 41 = 557. You also have to subtract the code that makes the jump, 51. This leaves you with 716 - 557 - 51 = 108. But your not finished, you also have to exx out your code. So 108 - 4 - 4= 100. 100 t-states for 22,050. Going to 20,000 hz will give you an extra 74. So 174 is the magic number to work with.

As far as the source, you can delete all of the _44100: data. I just keep it because it took so long to make. You should also delete the _0: _1: stuff as that is my Huffman decompressor.

Memory wise. The whole thing runs in C000-FFFF. Which means that 4000-BFFF are free to use.

1,196,032 bytes. The first 1 is cut off in the memory menu. But this number makes sense as divides to 73 pages.

Anyways, I am going to use huffman compression. I am hoping that 13 bits is enough for a maximum. I would then multiply that to 14 bits and use a 16k look up table. I am also going to cut the rate to 20,000 so that I will have 74 extra t-states to work with.

Wow, that's actually pretty large. O_o Are you going to allow an option on your converter to select different sample rates so that people can include longer pieces?
*edit* this reminds me alot of Jim E's Realsound. =)

Prepare for epicness. I wrote my huffman compressor, (which was actually somewhat hard), and it got a ratio of 60%. That means 2 min and 20 seconds of music.

But!... Some of the numbers are encoded as 19 bits. 12 bits has pushed my decompressor 8 t-states over my max, which is acceptable, but 19 is just out of the question. So I am going to try to sound clip the edges of the song to fix the problem. I'll make a cut off of say 30 instances, and anything with less than 30, gets bumped closer to $80. I'm hoping that this can give me a smaller prefix and thereby make this possible.

Edit:
    That number is more like 400, not 30.