| Author |
Message |
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
 Posted: 15 Aug 2009 10:16:22 pm Post subject: |
|
|
No, what I mean is that you have a 2-bit sample which determines a pattern of 4 bits; that pattern gets written out to both lines of the link port at 20 kHz. The patterns would look something like this:
Code:
.align 8
outputValues0:
.db 0, 0, 0, 0, 0, 0, 0, 0
outputValues1:
.db 3, 0, 0, 0, 3, 0, 0, 0
outputValues2:
.db 3, 3, 0, 0, 3, 3, 0, 0
outputValues3:
.db 3, 3, 3, 0, 3, 3, 3, 0
The samples themselves don't come at 20 kHz, they only come at 4 kHz or whatever.
You can try lowering the PWM frequency below 20 kHz; chances are that the headphones most people will be using can't actually produce sounds that high-pitched. Play around with it and let us know what you discover.
Of course it isn't "really" 2-bit sound, since you're still only outputting two voltage levels, but (if the PWM is fast enough) it will sound the same to the human ear. (I wonder if, on the TI-85, 86, or old-style 82, you could actually get more than two voltage levels by using non-standard output values. But I digress.)
Stereo is another thing altogether - you could in fact do stereo, if you wanted, using the exact same method. 4-bit input values yielding 2.3/1.6-bit mid/side joint stereo.  But that makes your input files even larger... |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 15 Aug 2009 10:29:24 pm Post subject: |
|
|
tiuser1010 wrote: So seren, is there some sort of command to sound maybe something involving the set insturction
To make sound you have to use the I/O link port (Port 0).
When you use the link port, you generally send out two bits of information to another calculator (%000000??)
However, if you plug in earpieces or a speaker, your sound device will be receiving the information and it will think it is sound. One of the two bits is used for the left speaker, and one for the right.
Let's say you want to run some sound at 8.000 kHz. Then you need to update the piece of information for the sound every 6000000/8000 clock cycles = 750 (approximately, not exact). So you would send out new information every 750 cycles.
Because of the bitwise nature of this method, and the size restraints of the calculator, usually it is best to play sound in a midi-style (think of gameboy colour sound). That is, have a byte saying that the bit of information being sent out the port oscillates (changes) every X clock cycles and lasts for Y amount of time. It's a lot more compact than the way I am working with the sound right now.
I'm afraid I don't follow you at all, Maximus. What's the 2-bit sample, how does it determine a 4-bit pattern, and how do 4 bits get written out to the linkport? Sorry, I guess my brain neurons are on lunch break right now.
Last edited by Guest on 15 Aug 2009 10:34:56 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 15 Aug 2009 11:15:56 pm Post subject: |
|
|
Sorry. Say you have 2-bit samples. That gives you four possible sample values, corresponding to four amplitude values in your original recording. Each of them is represented by a square wave:
Code:
0 _________________________________
_ _ _ _
1 _| |_____| |_____| |_____| |_____
<-> 12.5 µs
___ ___ ___ ___
2 _| |___| |___| |___| |___
<---> 25 µs
_____ _____ _____ _____
3 _| |_| |_| |_| |_
<-----> 37.5 µs
(There are other ways you could do it, of course.) To play your song, you switch from one of these square waves to another, every 250 µs or so. To the human ear, this should sound very much like it would if you were switching between constant voltages of 0, 12.5, 2.5, and 3.75 volts.
What I was suggesting was a fairly quick way of generating these square waves, given that you don't have very much CPU power to work with. The wave itself is stored in a table, as I described, and after every few instructions you would stop, get the next value from the buffer, and write it out to the link port. |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 16 Aug 2009 12:46:08 pm Post subject: |
|
|
Wow!
Amazing game!
My wish list is:
Better sound: I know you already want this, but I thought I'd mention it.
A mode where you just see a screen like an ipod's and can just listen to music. Since you already have the huge music files avalible this would be great (An it would have a little bit better sound).
Less memory used: Mabey compress the song files?
Overall incredible! This game will be awesome when finished! Great job Seren! |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 16 Aug 2009 03:39:06 pm Post subject: |
|
|
FloppusMaximus wrote: Sorry. Say you have 2-bit samples. That gives you four possible sample values, corresponding to four amplitude values in your original recording. Each of them is represented by a square wave:
Code: 0 _________________________________
_ _ _ _
1 _| |_____| |_____| |_____| |_____
<-> 12.5 µs
___ ___ ___ ___
2 _| |___| |___| |___| |___
<---> 25 µs
_____ _____ _____ _____
3 _| |_| |_| |_| |_
<-----> 37.5 µs
(There are other ways you could do it, of course.) To play your song, you switch from one of these square waves to another, every 250 µs or so. To the human ear, this should sound very much like it would if you were switching between constant voltages of 0, 1.25, 2.5, and 3.75 volts.
What I was suggesting was a fairly quick way of generating these square waves, given that you don't have very much CPU power to work with. The wave itself is stored in a table, as I described, and after every few instructions you would stop, get the next value from the buffer, and write it out to the link port.
This is exactly what I was suggesting with PWM. I've tried it before, and got it to play 8-bit wav files (not as well as Realsound, but that's because I didn't put too much effort into it). I got it to play beeps at different volumes. It works just like grayscale. You're really turning it on and off quickly, but how it appears to our eyes (ears) is the average. |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 16 Aug 2009 04:26:05 pm Post subject: |
|
|
Will be trying the PWM tomorrow or the day after, when I have time.
ztrumpet wrote: Wow!
Amazing game!
My wish list is:
Better sound: I know you already want this, but I thought I'd mention it.
A mode where you just see a screen like an ipod's and can just listen to music. Since you already have the huge music files avalible this would be great (An it would have a little bit better sound).
Less memory used: Mabey compress the song files?
Overall incredible! This game will be awesome when finished! Great job Seren!
You can simulate I-Pod mode by playing a song and not bothering to hit any notes  . I might consider a separate mode which performs PWM at a greater frequency than during the game - but that would be an extra feature after I'm done with the main game.
I'm not sure how I would go about compressing it (and decompressing it in realtime?). I'll be willing to listen to any viable suggestions. |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 16 Aug 2009 04:42:16 pm Post subject: |
|
|
| You could compress when you make the song (on the computer) and decompress it before the song (and have a loading bar like in guitar hero ). |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 16 Aug 2009 11:05:27 pm Post subject: |
|
|
ztrumpet wrote: You could compress when you make the song (on the computer) and decompress it before the song (and have a loading bar like in guitar hero ).
With the always amusing comments as well |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 17 Aug 2009 11:02:34 am Post subject: |
|
|
Where would I decompress it to? The decompressed file could easily take 500kb. And let's say I managed to compress it down to 300kb. That means the user would need 800kb.
How much memory does each type of calculator in the Ti-83+ series have? |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 17 Aug 2009 11:22:58 am Post subject: |
|
|
Here's the memory:
83: Ram-27KB Rom-None
83+: Ram-24KB Rom-160KB
83+SE: Ram-24KB Rom-1.5 MB
84+: Ram-24KB Rom-480KB
84+SE: Ram-24KB Rom-1.5MB
From: http://tibasicdev.wikidot.com/thecalcs
Oh and I think it would be better to be compressed even though you'd need both at once. If you posted the code in AppVars for the songs, we could help you compress them. (If you don't have a method.)
Last edited by Guest on 17 Aug 2009 11:26:48 am; edited 1 time in total |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 17 Aug 2009 11:35:47 am Post subject: |
|
|
Well, since I'm about to try out PWM, I don't have anything definite for my AppVar (depends how things end up).
In any of the attached files numerical AppVar files, if you start at offset 4A, and go all the way down to the end (not including the last two bytes), that will be the sound information in the AppVar that I have so far. |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 17 Aug 2009 11:43:26 am Post subject: |
|
|
I guess what I'm saying is if the AppVars are like 10011001011001011111 the they might compress to 12221122115 with the numbers refering to how many of a type (1 for on, 0 for off) are in a row. Then you decompress.
If you wanted to use this method, you could use different tokens for each number of 1s or 0s in a row. If it ever maxed it out, you could make it so it would continue counting on the next one but keep the number (1 or 0) of the previous one.
Last edited by Guest on 17 Aug 2009 11:44:12 am; edited 1 time in total |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 17 Aug 2009 11:44:30 am Post subject: |
|
|
ztrumpet wrote: Here's the memory:
83: Ram-27KB Rom-None
83+: Ram-24KB Rom-160KB
83+SE: Ram-24KB Rom-1.5 MB
84+: Ram-24KB Rom-480KB
84+SE: Ram-24KB Rom-1.5MB
well, that's only the user accessible memory (the one you can use to store programs...). SE calc (83+SE/84+/84+SE) all have 128kb of memory available so if you write your app as a flash app and take the trouble not to use any TIOS routines (at least not any that need the default RAM page to be swapped in bank B and C) you can have as much as 32kb of data available for (temporary) storage at any time. This of course is much more interesting in a compressed-data scenario : store compressed data into prgms/appvars (or even apps directly), uncompress it into extra ram pages and play.
As for the concern of, err, say "additive decompression" : you need not decompress the whole file at the start. Instead you should uncompress a sufficiently large part that will take some time to play and decompress the rest as you go, interlacing game logic, sound and decompression. To reduce the overhead as much as possible a circular buffer of fixed size (power of two if possible) would help. If you buffer enough data you will be able to reduce the "frequency" of decompression chunks thus avoiding to slow down the game.
If you go for compression/decompression it might be worth enabling fast mode on SE calculators to keep things as fast as possible (if not done already...) |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 17 Aug 2009 12:17:04 pm Post subject: |
|
|
ztrumpet wrote: I guess what I'm saying is if the AppVars are like 10011001011001011111 the they might compress to 12221122115 with the numbers refering to how many of a type (1 for on, 0 for off) are in a row. Then you decompress.
If you wanted to use this method, you could use different tokens for each number of 1s or 0s in a row. If it ever maxed it out, you could make it so it would continue counting on the next one but keep the number (1 or 0) of the previous one.
It isn't like that. I'm operating at a bit level, so I have %01101110, %11100011, etc. I don't know if the second method is worth it - especially if I operate at a 2-bit level. Well, it probably would reduce the size a bit - but by how much I wonder.
fullmetalcoder wrote: ztrumpet wrote: Here's the memory:
83: Ram-27KB Rom-None
83+: Ram-24KB Rom-160KB
83+SE: Ram-24KB Rom-1.5 MB
84+: Ram-24KB Rom-480KB
84+SE: Ram-24KB Rom-1.5MB
well, that's only the user accessible memory (the one you can use to store programs...). SE calc (83+SE/84+/84+SE) all have 128kb of memory available so if you write your app as a flash app and take the trouble not to use any TIOS routines (at least not any that need the default RAM page to be swapped in bank B and C) you can have as much as 32kb of data available for (temporary) storage at any time. This of course is much more interesting in a compressed-data scenario : store compressed data into prgms/appvars (or even apps directly), uncompress it into extra ram pages and play.
As for the concern of, err, say "additive decompression" : you need not decompress the whole file at the start. Instead you should uncompress a sufficiently large part that will take some time to play and decompress the rest as you go, interlacing game logic, sound and decompression. To reduce the overhead as much as possible a circular buffer of fixed size (power of two if possible) would help. If you buffer enough data you will be able to reduce the "frequency" of decompression chunks thus avoiding to slow down the game.
If you go for compression/decompression it might be worth enabling fast mode on SE calculators to keep things as fast as possible (if not done already...)
Well, I'm resigned to the fact that normal Ti-83+ calculators don't have the memory for actual sound - and I believe that all other versions of calculators have the 15 mHz processor. So perhaps I could base a Ti-83+ version off what I have so far, and change it some more for all other versions that support both 15 mHz and sound. This should allow time for decompression, I'd think. |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 17 Aug 2009 12:28:23 pm Post subject: |
|
|
Seren wrote: I believe that all other versions of calculators have the 15 mHz processor. Yup, you're right. |
|
| Back to top |
|
|
DigiTan
Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003
Posts: 4468
|
| Posted: 17 Aug 2009 01:18:05 pm Post subject: |
|
|
ztrumpet wrote: Here's the memory:
83: Ram-27KB Rom-None
83+: Ram-24KB Rom-160KB
83+SE: Ram-24KB Rom-1.5 MB
84+: Ram-24KB Rom-480KB
84+SE: Ram-24KB Rom-1.5MB
No TI-82? I'm insulted! |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 17 Aug 2009 02:06:38 pm Post subject: |
|
|
Total amount of user RAM:
TI-85: 28280
TI-82: 29002
TI-83: 27463
TI-73: 25135
TI-83+: 24785
TI-86: 98304
:)
(of course, some of this is taken up by variables like equations and Ans that cannot be deleted.)
Last edited by Guest on 17 Aug 2009 02:07:34 pm; edited 1 time in total |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 17 Aug 2009 02:44:17 pm Post subject: |
|
|
FloppusMaximus wrote: Total amount of user RAM:
TI-85: 28280
TI-82: 29002
TI-83: 27463
TI-73: 25135
TI-83+: 24785
TI-86: 98304
:)
(of course, some of this is taken up by variables like equations and Ans that cannot be deleted.)
and this:
http://www.unitedti.org/index.php?showtopic=8883
EDIT: By the way, can I just use the shadow registers in my program without saving their contents (does the OS store anything important in them during the normal running of the calculator)?
EDIT2: What's the delay required when adjusting port 01 (at 15 mHz, that is).
Last edited by Guest on 17 Aug 2009 03:16:43 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 17 Aug 2009 03:27:11 pm Post subject: |
|
|
You can use the shadow registers freely if you disable interrupts. You need to disable interrupts while playing music anyway, if you want to get reliable PWM.
I don't know about port 1. Do some experiments and find out? |
|
| Back to top |
|
|
Seren
Newbie
Joined: 14 Aug 2009
Posts: 27
|
| Posted: 17 Aug 2009 09:41:18 pm Post subject: |
|
|
Well, using 15 mHz I managed to do PWM at 48.000 kHz
Each 2 bits of information represented 6 bits
Code:
00
0,0,0,0,0,0
01
0,0,3,0,0,3
10
0,3,3,0,3,3
11
3,3,3,3,3,3
(I did it a bit differently, dividing in 3 and having both a silent bottom and top - but it sound awesome!)
I've attached the preliminary file - the actual game is disabled (only the delete button works) - but the new audio system is in (along with a new AppVar for the new type, taking a song from GH2, Sweet Child O' Mine).
I switched it around a bit so the the difficulty is now numbered, and the sound files alphanumeric, because, well, I ran out of numbers (0-9 = 10 = 5 minutes of song). I believe all songs in GH fall under 13 minutes (Ah well, really a minor issue).
Anywho, listen to the new audio - 2-bit all the way!
Now it's time to adapt the rest of my code - which shouldn't take an unreasonable amount of time, since I just need to do a whole lot of shifting (and recounting the amount of clock ticks all my instructions take >_<).
Thanks Maximus & 84calcpersondude. |
|
| Back to top |
|
|
|
Project Ideas/Start New Projects => Your Projects
