| Oscillation Overthruster [message #342620] |
Tue, 25 April 2017 16:00  |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
Here is a fun little audio toy to play with. Nowhere near as cool as Michael Mahon’s toys, but it has some neat features: High Frequency Oscillator sampling a Low Frequency Oscillator’s waveform with envelope control. You will hear that the upper octave gets out of tune: a feature of having a minimal 100 cycle sampling loop. Just ignore that octave it annoys you. Try playing with the LFO at a value around 4-8.
This was also an experiment in embedded PLASMA, thus its location along with the source.
The link to a bootable floppy image that lets you jump right into it: https://github.com/dschmenk/PLASMA/raw/master/src/samplesrc/ a2pwm/lfo.po
Enjoy!
|
|
|
|
| Re: Oscillation Overthruster [message #342622 is a reply to message #342620] |
Tue, 25 April 2017 17:40  |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
David Schmenk <dschmenk@gmail.com> wrote:
> Here is a fun little audio toy to play with. Nowhere near as cool as
> Michael Mahon’s toys, but it has some neat features: High Frequency
> Oscillator sampling a Low Frequency Oscillator’s waveform with envelope
> control. You will hear that the upper octave gets out of tune: a feature
> of having a minimal 100 cycle sampling loop. Just ignore that octave it
> annoys you. Try playing with the LFO at a value around 4-8.
>
> This was also an experiment in embedded PLASMA, thus its location along with the source.
>
> The link to a bootable floppy image that lets you jump right into it:
> https://github.com/dschmenk/PLASMA/raw/master/src/samplesrc/ a2pwm/lfo.po
>
> Enjoy!
>
Love the reference to Buckaroo Bonzai, Dave!
"No matter where you go, there you are."
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Oscillation Overthruster [message #342625 is a reply to message #342622] |
Tue, 25 April 2017 20:49 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
You're now my best friend!
SINED, SEELED, DELIVERED
On Tuesday, 25 April 2017 14:40:50 UTC-7, Michael J. Mahon wrote:
> David Schmenk <dschmenk@gmail.com> wrote:
>> Here is a fun little audio toy to play with. Nowhere near as cool as
>> Michael Mahon’s toys, but it has some neat features: High Frequency
>> Oscillator sampling a Low Frequency Oscillator’s waveform with envelope
>> control. You will hear that the upper octave gets out of tune: a feature
>> of having a minimal 100 cycle sampling loop. Just ignore that octave it
>> annoys you. Try playing with the LFO at a value around 4-8.
>>
>> This was also an experiment in embedded PLASMA, thus its location along with the source.
>>
>> The link to a bootable floppy image that lets you jump right into it:
>> https://github.com/dschmenk/PLASMA/raw/master/src/samplesrc/ a2pwm/lfo.po
>>
>> Enjoy!
>>
>
> Love the reference to Buckaroo Bonzai, Dave!
>
> "No matter where you go, there you are."
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Oscillation Overthruster [message #342646 is a reply to message #342620] |
Wed, 26 April 2017 17:42 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 25 April 2017 13:00:12 UTC-7, David Schmenk wrote:
> Here is a fun little audio toy to play with. Nowhere near as cool as Michael Mahon’s toys, but it has some neat features: High Frequency Oscillator sampling a Low Frequency Oscillator’s waveform with envelope control. You will hear that the upper octave gets out of tune: a feature of having a minimal 100 cycle sampling loop. Just ignore that octave it annoys you. Try playing with the LFO at a value around 4-8.
>
> This was also an experiment in embedded PLASMA, thus its location along with the source.
>
> The link to a bootable floppy image that lets you jump right into it: https://github.com/dschmenk/PLASMA/raw/master/src/samplesrc/ a2pwm/lfo.po
>
> Enjoy!
Now Version 1.1 with recordable and persistent macros. Also, some minimal documentation to explain it:
https://github.com/dschmenk/PLASMA/tree/master/src/samplesrc /a2pwm
Download lfo.po disk image (self booting)
Kind of cool, even if I do say so myself.
|
|
|
|
| Re: Oscillation Overthruster [message #342673 is a reply to message #342620] |
Thu, 27 April 2017 23:41 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
|
Here is something interesting: When testing OO on different models of the Apple II, the sound output of the PWM code wasn't the same loudness, especially at lower frequencies. On a whim, I went to the monitor and toggled the speaker once, then re-ran OO. The loudness was back up. We know that the Apple II toggles the speaker cone in or out whenever $C030 is accessed, but we don't know the phase (whether the position of the cone is in or out). Apparently it matters when trying to adjust volume levels with PWM. So I added a hack to toggle the phase of the speaker in case you were unlucky enough to launch OO with the wrong phase. I do much of my testing on Virtual ][ and an Apple //c. Never saw a problem until I tried an Apple ][+ and a //e. The //c is unaffected by the phase, but the ][+ and //e are significantly impacted. So there is now version 1.2 that flips the phase of the speaker with the '0' command (I couldn't think of a good mnemonic and 0 is far away from the other command keys so you have less chance of accidentally hitting it).
|
|
|
|
| Re: Oscillation Overthruster [message #342676 is a reply to message #342673] |
Fri, 28 April 2017 02:44 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, 28 April 2017 15:41:49 UTC+12, David Schmenk wrote:
> Here is something interesting: When testing OO on different models of the Apple II, the sound output of the PWM code wasn't the same loudness, especially at lower frequencies. On a whim, I went to the monitor and toggled the speaker once, then re-ran OO. The loudness was back up. We know that the Apple II toggles the speaker cone in or out whenever $C030 is accessed, but we don't know the phase (whether the position of the cone is in or out). Apparently it matters when trying to adjust volume levels with PWM. So I added a hack to toggle the phase of the speaker in case you were unlucky enough to launch OO with the wrong phase. I do much of my testing on Virtual ][ and an Apple //c. Never saw a problem until I tried an Apple ][+ and a //e. The //c is unaffected by the phase, but the ][+ and //e are significantly impacted. So there is now version 1.2 that flips the phase of the speaker with the '0' command (I couldn't think of a good mnemonic and 0 is far away from the other command keys so you have less chance of accidentally hitting it).
Yes, I've noticed this too. Surely Michael Mahon has some wisdom here, but here's a naive idea: If toggling for audio is fast enough that the speaker cone never uses its full tense/relax range (and I have no idea if this is the case) maybe toggling once, waiting for a short fixed time, and then starting the main audio routine might shift work better.
My naive idea is that the audio should sound more uniform if the speaker is toggled around a more central point in the tense/relax range, rather than at one of the extremes - which presumably gives the difference you noticed.
Sather has little to say about the speaker expect for the tense/relax nature of the circuit:
UTA2 Page 7-12 (or UTA2E Page 7-9)
The output of the audio flip-flop controls a simple amplifier which
drives the Apple's speaker. Current flow through the speaker is in only
one direction so the speaker action is tension/relax rather than
push/pull. Alternate references to $C03X tension the speaker diaphragm
then relax it, but the program cannot determine whether a $C03X
reference causes tension or relaxation. This dampens the possibilities
of complex program control of the speaker tension. In any case, an audio
cycle consists of a tension half cycle and a relaxation half cycle, so
two $C03X references are required per audio cycle.
Cheers,
Nick.
|
|
|
|
| Re: Oscillation Overthruster [message #342682 is a reply to message #342676] |
Fri, 28 April 2017 09:33 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, 27 April 2017 23:44:57 UTC-7, Nick Westgate wrote:
> On Friday, 28 April 2017 15:41:49 UTC+12, David Schmenk wrote:
>> Here is something interesting: When testing OO on different models of the Apple II, the sound output of the PWM code wasn't the same loudness, especially at lower frequencies. On a whim, I went to the monitor and toggled the speaker once, then re-ran OO. The loudness was back up. We know that the Apple II toggles the speaker cone in or out whenever $C030 is accessed, but we don't know the phase (whether the position of the cone is in or out). Apparently it matters when trying to adjust volume levels with PWM. So I added a hack to toggle the phase of the speaker in case you were unlucky enough to launch OO with the wrong phase. I do much of my testing on Virtual ][ and an Apple //c. Never saw a problem until I tried an Apple ][+ and a //e. The //c is unaffected by the phase, but the ][+ and //e are significantly impacted. So there is now version 1.2 that flips the phase of the speaker with the '0' command (I couldn't think of a good mnemonic and 0 is far away from the other command keys so you have less chance of accidentally hitting it).
>
> Yes, I've noticed this too. Surely Michael Mahon has some wisdom here, but here's a naive idea: If toggling for audio is fast enough that the speaker cone never uses its full tense/relax range (and I have no idea if this is the case) maybe toggling once, waiting for a short fixed time, and then starting the main audio routine might shift work better.
>
> My naive idea is that the audio should sound more uniform if the speaker is toggled around a more central point in the tense/relax range, rather than at one of the extremes - which presumably gives the difference you noticed.
>
> Sather has little to say about the speaker expect for the tense/relax nature of the circuit:
>
> UTA2 Page 7-12 (or UTA2E Page 7-9)
>
> The output of the audio flip-flop controls a simple amplifier which
> drives the Apple's speaker. Current flow through the speaker is in only
> one direction so the speaker action is tension/relax rather than
> push/pull. Alternate references to $C03X tension the speaker diaphragm
> then relax it, but the program cannot determine whether a $C03X
> reference causes tension or relaxation. This dampens the possibilities
> of complex program control of the speaker tension. In any case, an audio
> cycle consists of a tension half cycle and a relaxation half cycle, so
> two $C03X references are required per audio cycle.
>
> Cheers,
> Nick.
Nick-
Thanks for the Sather reference. I believe you're correct in that the speaker driver has more *oomph* (technical term) in one direction vs the other. That's what led me to try toggling the speaker by hand and re-running OO. I bet the //c has a stronger driver because it has that variable resistor for volume control and why it isn't an issue on that model. Kind of makes you wonder why Woz implemented the speaker control as a flip-flop and not just a direct value. Seems like it would have been less hardware to just hook bit 7 of $C030 right to the speaker. You'd have to write an explicit value there, but when did a little extra software ever put Woz off?
Dave...
|
|
|
|
| Re: Oscillation Overthruster [message #342683 is a reply to message #342676] |
Fri, 28 April 2017 09:49 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, 27 April 2017 23:44:57 UTC-7, Nick Westgate wrote:
> On Friday, 28 April 2017 15:41:49 UTC+12, David Schmenk wrote:
>> Here is something interesting: When testing OO on different models of the Apple II, the sound output of the PWM code wasn't the same loudness, especially at lower frequencies. On a whim, I went to the monitor and toggled the speaker once, then re-ran OO. The loudness was back up. We know that the Apple II toggles the speaker cone in or out whenever $C030 is accessed, but we don't know the phase (whether the position of the cone is in or out). Apparently it matters when trying to adjust volume levels with PWM. So I added a hack to toggle the phase of the speaker in case you were unlucky enough to launch OO with the wrong phase. I do much of my testing on Virtual ][ and an Apple //c. Never saw a problem until I tried an Apple ][+ and a //e. The //c is unaffected by the phase, but the ][+ and //e are significantly impacted. So there is now version 1.2 that flips the phase of the speaker with the '0' command (I couldn't think of a good mnemonic and 0 is far away from the other command keys so you have less chance of accidentally hitting it).
>
> Yes, I've noticed this too. Surely Michael Mahon has some wisdom here, but here's a naive idea: If toggling for audio is fast enough that the speaker cone never uses its full tense/relax range (and I have no idea if this is the case) maybe toggling once, waiting for a short fixed time, and then starting the main audio routine might shift work better.
>
> My naive idea is that the audio should sound more uniform if the speaker is toggled around a more central point in the tense/relax range, rather than at one of the extremes - which presumably gives the difference you noticed.
>
> Sather has little to say about the speaker expect for the tense/relax nature of the circuit:
>
> UTA2 Page 7-12 (or UTA2E Page 7-9)
>
> The output of the audio flip-flop controls a simple amplifier which
> drives the Apple's speaker. Current flow through the speaker is in only
> one direction so the speaker action is tension/relax rather than
> push/pull. Alternate references to $C03X tension the speaker diaphragm
> then relax it, but the program cannot determine whether a $C03X
> reference causes tension or relaxation. This dampens the possibilities
> of complex program control of the speaker tension. In any case, an audio
> cycle consists of a tension half cycle and a relaxation half cycle, so
> two $C03X references are required per audio cycle.
>
> Cheers,
> Nick.
Hi Nick-
Thanks for the Sather reference. I'm sure the speaker driver has more *oomph* (technical term) in one direction vs the other. That's what led me to try toggling the speaker by hand before re-running OO. You can definitely hear an audible "click" more on one toggle than the next.
I'd be interested to hear what Michael has to say about DAC522 and his experience with the audible differences in phase. For OO, I use the PWM for volume control of the speaker clicks, not quite like Michael's DAC522 which is more like a traditional PWM DAC output.
I bet the //c has a stronger speaker driver because of the variable resistor used for volume control and why I didn't have an issue when testing on that platform.
Dave...
|
|
|
|
| Re: Oscillation Overthruster [message #342689 is a reply to message #342683] |
Fri, 28 April 2017 16:19 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
David Schmenk <dschmenk@gmail.com> wrote:
> On Thursday, 27 April 2017 23:44:57 UTC-7, Nick Westgate wrote:
>> On Friday, 28 April 2017 15:41:49 UTC+12, David Schmenk wrote:
>>> Here is something interesting: When testing OO on different models of
>>> the Apple II, the sound output of the PWM code wasn't the same
>>> loudness, especially at lower frequencies. On a whim, I went to the
>>> monitor and toggled the speaker once, then re-ran OO. The loudness was
>>> back up. We know that the Apple II toggles the speaker cone in or out
>>> whenever $C030 is accessed, but we don't know the phase (whether the
>>> position of the cone is in or out). Apparently it matters when trying
>>> to adjust volume levels with PWM. So I added a hack to toggle the phase
>>> of the speaker in case you were unlucky enough to launch OO with the
>>> wrong phase. I do much of my testing on Virtual ][ and an Apple //c.
>>> Never saw a problem until I tried an Apple ][+ and a //e. The //c is
>>> unaffected by the phase, but the ][+ and //e are significantly
>>> impacted. So there is now version 1.2 that flips the phase of the
>>> speaker with the '0' command (I couldn't think of a good mnemonic and 0
>>> is far away from the other command keys so you have less chance of
>>> accidentally hitting it).
>>
>> Yes, I've noticed this too. Surely Michael Mahon has some wisdom here,
>> but here's a naive idea: If toggling for audio is fast enough that the
>> speaker cone never uses its full tense/relax range (and I have no idea
>> if this is the case) maybe toggling once, waiting for a short fixed
>> time, and then starting the main audio routine might shift work better.
>>
>> My naive idea is that the audio should sound more uniform if the speaker
>> is toggled around a more central point in the tense/relax range, rather
>> than at one of the extremes - which presumably gives the difference you noticed.
>>
>> Sather has little to say about the speaker expect for the tense/relax
>> nature of the circuit:
>>
>> UTA2 Page 7-12 (or UTA2E Page 7-9)
>>
>> The output of the audio flip-flop controls a simple amplifier which
>> drives the Apple's speaker. Current flow through the speaker is in only
>> one direction so the speaker action is tension/relax rather than
>> push/pull. Alternate references to $C03X tension the speaker diaphragm
>> then relax it, but the program cannot determine whether a $C03X
>> reference causes tension or relaxation. This dampens the possibilities
>> of complex program control of the speaker tension. In any case, an audio
>> cycle consists of a tension half cycle and a relaxation half cycle, so
>> two $C03X references are required per audio cycle.
>>
>> Cheers,
>> Nick.
>
> Hi Nick-
>
> Thanks for the Sather reference. I'm sure the speaker driver has more
> *oomph* (technical term) in one direction vs the other. That's what led
> me to try toggling the speaker by hand before re-running OO. You can
> definitely hear an audible "click" more on one toggle than the next.
>
> I'd be interested to hear what Michael has to say about DAC522 and his
> experience with the audible differences in phase. For OO, I use the PWM
> for volume control of the speaker clicks, not quite like Michael's DAC522
> which is more like a traditional PWM DAC output.
>
> I bet the //c has a stronger speaker driver because of the variable
> resistor used for volume control and why I didn't have an issue when
> testing on that platform.
>
> Dave...
>
The key observation is that it's different on different A II models.
The A II, A II+, and A IIe all use essentially the same speaker drive
circuit--an emitter follower--which provides plenty of drive when it turns
on, but only turns off the drive current for the off state. This means the
speaker is "driven" on, but not off on these machines.
A simple experiment will demonstrate this. Go into the monitor and toggle
the speaker repeatedly. Notice a sharp "tick" on one toggle and a duller
"tum" on the other. The low impedance "on" drive damps cone oscillations
quickly, while the higher impedance "off" release allows the cone a more
undamped oscillation at its natural frequency.
The A IIc and A IIgs both have audio amplifiers to drive the speaker, and
therefore have much more symmetrical output.
Interestingly, the later model A IIe's have a spot for an audio amplifier
on the PC board, but it's unpopulated.
My synth programs typically start and end sounds asymetrically (they "idle"
at 6 cycles/40 cycles to prevent "pops" when a sound starts or finishes),
but sounds generally use most of the available PWM range, and so are less
sensitive to the initial speaker state.
It would be possible to idle at 23/23, but this would break all the code
into 19 cycle timed chunks instead of half as many 36 cycle chunks, which
is hard enough to get right. ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Oscillation Overthruster [message #342699 is a reply to message #342689] |
Fri, 28 April 2017 20:15 |
David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Friday, 28 April 2017 13:19:47 UTC-7, Michael J. Mahon wrote:
> David Schmenk <dschmenk@gmail.com> wrote:
>> On Thursday, 27 April 2017 23:44:57 UTC-7, Nick Westgate wrote:
>>> On Friday, 28 April 2017 15:41:49 UTC+12, David Schmenk wrote:
>>>> Here is something interesting: When testing OO on different models of
>>>> the Apple II, the sound output of the PWM code wasn't the same
>>>> loudness, especially at lower frequencies. On a whim, I went to the
>>>> monitor and toggled the speaker once, then re-ran OO. The loudness was
>>>> back up. We know that the Apple II toggles the speaker cone in or out
>>>> whenever $C030 is accessed, but we don't know the phase (whether the
>>>> position of the cone is in or out). Apparently it matters when trying
>>>> to adjust volume levels with PWM. So I added a hack to toggle the phase
>>>> of the speaker in case you were unlucky enough to launch OO with the
>>>> wrong phase. I do much of my testing on Virtual ][ and an Apple //c.
>>>> Never saw a problem until I tried an Apple ][+ and a //e. The //c is
>>>> unaffected by the phase, but the ][+ and //e are significantly
>>>> impacted. So there is now version 1.2 that flips the phase of the
>>>> speaker with the '0' command (I couldn't think of a good mnemonic and 0
>>>> is far away from the other command keys so you have less chance of
>>>> accidentally hitting it).
>>>
>>> Yes, I've noticed this too. Surely Michael Mahon has some wisdom here,
>>> but here's a naive idea: If toggling for audio is fast enough that the
>>> speaker cone never uses its full tense/relax range (and I have no idea
>>> if this is the case) maybe toggling once, waiting for a short fixed
>>> time, and then starting the main audio routine might shift work better.
>>>
>>> My naive idea is that the audio should sound more uniform if the speaker
>>> is toggled around a more central point in the tense/relax range, rather
>>> than at one of the extremes - which presumably gives the difference you noticed.
>>>
>>> Sather has little to say about the speaker expect for the tense/relax
>>> nature of the circuit:
>>>
>>> UTA2 Page 7-12 (or UTA2E Page 7-9)
>>>
>>> The output of the audio flip-flop controls a simple amplifier which
>>> drives the Apple's speaker. Current flow through the speaker is in only
>>> one direction so the speaker action is tension/relax rather than
>>> push/pull. Alternate references to $C03X tension the speaker diaphragm
>>> then relax it, but the program cannot determine whether a $C03X
>>> reference causes tension or relaxation. This dampens the possibilities
>>> of complex program control of the speaker tension. In any case, an audio
>>> cycle consists of a tension half cycle and a relaxation half cycle, so
>>> two $C03X references are required per audio cycle.
>>>
>>> Cheers,
>>> Nick.
>>
>> Hi Nick-
>>
>> Thanks for the Sather reference. I'm sure the speaker driver has more
>> *oomph* (technical term) in one direction vs the other. That's what led
>> me to try toggling the speaker by hand before re-running OO. You can
>> definitely hear an audible "click" more on one toggle than the next.
>>
>> I'd be interested to hear what Michael has to say about DAC522 and his
>> experience with the audible differences in phase. For OO, I use the PWM
>> for volume control of the speaker clicks, not quite like Michael's DAC522
>> which is more like a traditional PWM DAC output.
>>
>> I bet the //c has a stronger speaker driver because of the variable
>> resistor used for volume control and why I didn't have an issue when
>> testing on that platform.
>>
>> Dave...
>>
>
> The key observation is that it's different on different A II models.
>
> The A II, A II+, and A IIe all use essentially the same speaker drive
> circuit--an emitter follower--which provides plenty of drive when it turns
> on, but only turns off the drive current for the off state. This means the
> speaker is "driven" on, but not off on these machines.
>
> A simple experiment will demonstrate this. Go into the monitor and toggle
> the speaker repeatedly. Notice a sharp "tick" on one toggle and a duller
> "tum" on the other. The low impedance "on" drive damps cone oscillations
> quickly, while the higher impedance "off" release allows the cone a more
> undamped oscillation at its natural frequency.
>
> The A IIc and A IIgs both have audio amplifiers to drive the speaker, and
> therefore have much more symmetrical output.
>
> Interestingly, the later model A IIe's have a spot for an audio amplifier
> on the PC board, but it's unpopulated.
>
> My synth programs typically start and end sounds asymetrically (they "idle"
> at 6 cycles/40 cycles to prevent "pops" when a sound starts or finishes),
> but sounds generally use most of the available PWM range, and so are less
> sensitive to the initial speaker state.
>
> It would be possible to idle at 23/23, but this would break all the code
> into 19 cycle timed chunks instead of half as many 36 cycle chunks, which
> is hard enough to get right. ;-)
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Thanks for the great information, Michael. Always educational.
Here is the Apple II playing Happy Birthday to itself (4 different ways). I had to rewrite the sequence playback to get it fast enough to not pause between state updates.
https://www.youtube.com/watch?v=BBKYpq11JJc
Dave....
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
