Hello,
How do I output sound through the link port in pseudocode? And a textual explanation would be nice too.
Thanks!
I'll do the textual explanation Very Happy
Alternate bits 0 and 1 of port 0, and the frequency of the alternation is the frequency of the sound, e.g. changing port 0 from 0 to 3 and back 440 times a second will produce a 440Hz sound (An "A")
To control frequency, you can use the LCD, crystal timers, a certain piece of code, or just about anything else that will delay a controllable amount of time.
Thanks! By alternate, should I have them both on, then both off, or one on, one off, then one off, and one on?
SirCmpwn wrote:
Thanks! By alternate, should I have them both on, then both off, or one on, one off, then one off, and one on?
Doesn't make a difference. If you want different frequencies in different ears, the question is moot anyway, because you'll be varying the state in different ears at different rates. I think there may already be a topic on this with more information; lemme look.

Here it is:
http://www.cemetech.net/forum/viewtopic.php?t=4773

KermMartian wrote:
gain enough voltage or something similar, why is that?
So as you correctly noted, the ring and the tip each correspond to one ear of classic headphones. Recall from your basic physics or music class that sound is vibrations of the air. In headphones, vibrations are created by a paper or plastic diaphragm moving back and forth. The faster it vibrates, the higher the note; the slower, the lower. The bigger the amplitude of the vibration (how far it moves from neutral), the louder the note. TI sound is based on the fact that at logical high, the linkport output is 0v; at logical low, the linkport output is 5v. By quickly switching between 0v and 5v, you can make the diaphragms in the headphones vibrate and create sound. Of course, because you only have two voltages to work with, you therefore cannot change the volume of the music (well, you could do a PWM scheme, but it would sound really awkward), only the frequency. Careful cycle counting, or use of interrupts, will allow you to switch the state of the link port at a set speed and produce a desired frequency.

Makes sense? If that all sunk in, I'll next discuss monophonic, stereo (biphonic), and quadraphonic music.
Hmm, nice. By the way, I'm working with 90 MHz here. I probably have enough time to decode an MP3 as I play it Razz.
So, are you doing Nspire programming?
If you aren't using an 83+ Series calc but an Nspire, that's something completely different. Accessing the 84+ keypad's link port from ARM assembly is more complicated than with z80; I'm not entirely sure we know how to manipulate the link port from user code.
calcdude84se wrote:
If you aren't using an 83+ Series calc but an Nspire, that's something completely different. Accessing the 84+ keypad's link port from ARM assembly is more complicated than with z80; I'm not entirely sure we know how to manipulate the link port from user code.
We most certainly do. CALCnet, for example, has been tested working fine on Nspires, but that's mostly because I build in a lot of safeties for wonky timing. As far as I know link-port based sound things don't work too well. And now I see that you said "ARM assembly", so I take back what I said.
Yeah, I meant from user programs on the Nspire in ARM assembly. Very Happy
According to hackspire, it's just a memory mapped I/O port.
calcdude84se wrote:
Yeah, I meant from user programs on the Nspire in ARM assembly. Very Happy
Yeah, now I get that. Razz What's the point of writing in ARM assembly instead of C/C++ though? Razz Personally I'd prefer to write a little audio driver and then forget about ARM ASM.
Yeah, I'm thinking that C/C++ would be nicer. We have plenty of CPU time for the overhead. However, it may cause problems with timing.
You shouldn't rely on any specific timing for ARM assembly, due to caches and the like. It's better to use timers for something that needs precise timing.
Well, I just got my environment set up correctly mere moments ago, so now I actually have to learn Razz
calc84maniac wrote:
You shouldn't rely on any specific timing for ARM assembly, due to caches and the like. It's better to use timers for something that needs precise timing.
Caches? You mean preemptive and predictive execution? Actually, what indeed does the ARM execution unit do in terms of CPU optimizations?
Nah, I'm talking about code/data caches. It will probably run slower whenever there is a cache miss.
calc84, didn't you have trouble getting it to work on the 83+ emulator?
Edit: Or was that resolved?
calcdude84se wrote:
calc84, didn't you have trouble getting it to work on the 83+ emulator?
Edit: Or was that resolved?
Why don't you ask me? Laughing I had no trouble getting it to work for sound (mobileTunes) or networking (CALCnet) on the 84+SE emulator, as per reports from users.
I meant on the 83+ emulator he had been writing Wink
calcdude84se wrote:
I meant on the 83+ emulator he had been writing Wink
Ahhh, gotcha. Well, I have faith in calc84, so if TI can do it for their emulator, I'm sure he can do it for his.
  
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 3
» 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