How is the IIgs beep generated?
D Finnigan
IIgs beep generated? Some say it is an algorithmically drawn waveform, fed
to the DOC, while others suppose that it is generated by the Ensoniq.
Anyone have the full details?
Sheppy
> Some discussion on the Wikipedia page got me wondering: how is the Apple
> IIgs beep generated? Some say it is an algorithmically drawn waveform, fed
> to the DOC, while others suppose that it is generated by the Ensoniq.
The Apple IIgs beep is actually generated old-school, by triggering
the speaker port at $C030. That's why the Gus emulator had sound
resources for the IIgs system beep sound effect; it didn't emulate the
$C030 sound toggle register, so to get the system beep working, they
patched the beep routines to play a Mac sound resource file instead.
Sheppy
Toinet
1 REM
2 REM Beep
3 REM
4 REM Sheppy is right
5 REM $C030 is your friend
6 REM
10 PRINT CHR$(7)
20 GOTO 10
Antoine
Jayson Smith
located? You're saying the "Bonk" heard at bootup is generated just by using
$C030?
Jayson
"D Finnigan" <dog...@macgui.com> wrote in message
news:dog_cow-1...@macgui.com...
Toinet
<ihatespamratguynospample...@insightbb.spamsucks.com> wrote:
> I'm interested in this too. Where is the code for generating the GS beep
> located? You're saying the "Bonk" heard at bootup is generated just by using
> $C030?
> Jayson
>
>
> news:dog_cow-1...@macgui.com...
>
>
>
> > Some discussion on the Wikipedia page got me wondering: how is the Apple
> > IIgs beep generated? Some say it is an algorithmically drawn waveform, fed
> > to the DOC, while others suppose that it is generated by the Ensoniq.
>
> > Anyone have the full details?
There are several boing boing calls in the IIgs:
BELL at $FF3A
BELL1 at $FBDD
BELL1.2 at $FBE2
BELL2 at $FBE4
And the one used is BELL. It is called during boot, switching to the
monitor, etc.
antoine
Mitchell Spector
Here's a question, one I've been curious about the past twenty years:
Can you reproduce the IIgs "beep" on a stock Apple IIe?
Mitchell Spector
Michael J. Mahon
> Here's a question, one I've been curious about the past twenty years:
> Can you reproduce the IIgs "beep" on a stock Apple IIe?
It can be played using DAC522, but with 5-bit rather than 8-bit
precision, so it will be a little "rougher". Still, it would be
a nice hack. ;-)
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."
Michael J. Mahon
> Mitchell Spector wrote:
>
>> Here's a question, one I've been curious about the past twenty years:
>> Can you reproduce the IIgs "beep" on a stock Apple IIe?
>
>
> It can be played using DAC522, but with 5-bit rather than 8-bit
> precision, so it will be a little "rougher". Still, it would be
> a nice hack. ;-)
Can someone point me to the "bong" sound in the IIgs ROM?
I'll extract it and try it out on SOUND.EDITOR.
mdj
> Michael J. Mahon wrote:
> > Mitchell Spector wrote:
>
> >> Here's a question, one I've been curious about the past twenty years:
> >> Can you reproduce the IIgs "beep" on a stock Apple IIe?
>
> > It can be played using DAC522, but with 5-bit rather than 8-bit
> > precision, so it will be a little "rougher". Still, it would be
> > a nice hack. ;-)
>
> Can someone point me to the "bong" sound in the IIgs ROM?
>
> I'll extract it and try it out on SOUND.EDITOR.
Isn't the pitch and duration set by control panel parameters? It'd be
easy enough to hack the gs routine into a IIe ROM (if you don't
already use the self-test for other interesting things), but setting
the parameters is much harder.
Matt
Jerry
You could do something similar, but since the ROM modifies the volume
as part of its sound generator, it would not be quite the same.
On a ROM 01, the real code making the beep is at FF/A064:
FF/A064: 08 PHP
FF/A065: 78 SEI
FF/A066: A9 B0 LDA #B0
FF/A068: 20 A8 FC JSR FCA8 ; ~80 ms delay
FF/A06B: AD 36 C0 LDA C036 ; slow mode: 1 MHz
FF/A06E: 48 PHA
FF/A06F: 29 7F AND #7F
FF/A071: 8D 36 C0 STA C036
FF/A074: DA PHA
FF/A075: 8B PHB
FF/A076: 20 82 F8 JSR F882 ; data-bank = $E1
FF/A079: AD DF 02 LDA 02DF
FF/A07C: 49 0F EOR #0F
FF/A07E: 8D 6D 01 STA 016D
FF/A081: 9C 6E 01 STZ 016E
FF/A084: C2 20 REP #20
FF/A086: A9 88 88 LDA #8888
FF/A089: 8D 69 01 STA 0169
FF/A08C: A9 00 20 LDA #2000
FF/A08F: 8D 6B 01 STA 016B
FF/A092: E2 30 SEP #30
FF/A094: AD CA 00 LDA 00CA ; bell volume from BRAM
FF/A097: 8D 6F 01 STA 016F ; working bell volume
FF/A09A: 48 PHA
FF/A09B: 18 CLC
FF/A09C: C2 30 REP #30
FF/A09E: AC 6D 01 LDY 016D
FF/A0A1: A2 50 02 LDX #0250
FF/A0A4: 88 DEY
FF/A0A5: D0 0B BNE A0B2 {+0B}
FF/A0A7: AC 6D 01 LDY 016D
FF/A0AA: 2E 69 01 ROL 0169
FF/A0AD: 90 03 BCC A0B2 {+03}
FF/A0AF: AD 30 C0 LDA C030 ; click
FF/A0B2: CA DEX
FF/A0B3: D0 18 BNE A0CD {+18}
FF/A0B5: A2 50 02 LDX #0250
FF/A0B8: E2 20 SEP #20
FF/A0BA: AD 6F 01 LDA 016F
FF/A0BD: F0 19 BEQ A0D8 {+19}
FF/A0BF: EA DEC ; drop volume one notch
FF/A0C0: 8D 6F 01 STA 016F
FF/A0C3: 8D CA 00 STA 00CA
FF/A0C6: 8D 3C C0 STA C03C ; bits 3..0 are volume
FF/A0C9: C2 20 REP #20
FF/A0CB: 80 06 BRA A0D3 {+06}
FF/A0CD: A9 05 00 LDA #0005
FF/A0D0: 3A DEC
FF/A0D1: D0 FD BNE A0D0 {-03}
FF/A0D3: CE 6B 01 DEC 016B
FF/A0D6: D0 CC BNE A0A4 {-34}
FF/A0D8: E2 30 SEP #30
FF/A0DA: 68 PLA
FF/A0DB: 8D CA 00 STA 00CA ; restore system bell volume
FF/A0DE: 8D 3C C0 STA C03C
FF/A0E1: AB PLB
FF/A0E2: FA PLX
FF/A0E3: A0 00 LDY #00
FF/A0E5: 68 PLA
FF/A0E6: 8D 36 C0 STA C036 ; restore system speed
FF/A0E9: 28 PLP
FF/A0EA: 60 RTS
FF/F882: F4 E1 E1 PEA E1E1
FF/F885: AB PLB
FF/F886: AB PLB
FF/F887: 60 RTS
--
Jerry awanderin at yahoo dot ca
Mitchell Spector
>Michael J. Mahon wrote:
>> Mitchell Spector wrote:
>>
>>> Here's a question, one I've been curious about the past twenty years:
>>> Can you reproduce the IIgs "beep" on a stock Apple IIe?
>>
>>
>> It can be played using DAC522, but with 5-bit rather than 8-bit
>> precision, so it will be a little "rougher". Still, it would be
>> a nice hack. ;-)
>
>Can someone point me to the "bong" sound in the IIgs ROM?
>
>I'll extract it and try it out on SOUND.EDITOR.
Not possible. It isn't a digitized waveform (like, say, the "Apple II!
shout in the ROM 3 firmware). In fact it isn't even produced by the
Ensoniq chip.
It's likely just toggling the speaker, very similar to how the Apple
II/+/e/c produce their own "beep" (the IIc+ has a different tone).
The IIgs "bonk" sounds very UN-Apple II-ish or IBM PC speaker-ish
for that matter, especially once you start playing with the pitch.
I wonder how it's produced, is it because of the 2.8 MHz CPU
or some extra sound circurity that is not found in the 8-bit Apple II,
but not part of the Ensoniq either?
So the question remains: Can you re-produce the IIgs beep
on a stock Apple IIe? (digitizing it doesn't count!) :)
Mitchell Spector
Michael J. Mahon
That shows you how little I use the IIgs! ;-)
But since it's done by toggling the speaker, with a processor speed
of 1MHz, it can certainly be generated on any Apple II.
Michael J. Mahon
> mdj wrote:
>
>> On Dec 3, 11:07 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>>
>>> Michael J. Mahon wrote:
>>>
>>>> Mitchell Spector wrote:
>>>
>>>
>>>>> Here's a question, one I've been curious about the past twenty
>>>>> years:
>>>>> Can you reproduce the IIgs "beep" on a stock Apple IIe?
>>>
>>>
>>>> It can be played using DAC522, but with 5-bit rather than 8-bit
>>>> precision, so it will be a little "rougher". Still, it would be
>>>> a nice hack. ;-)
>>>
>>>
>>> Can someone point me to the "bong" sound in the IIgs ROM?
>>>
>>> I'll extract it and try it out on SOUND.EDITOR.
>>
>>
>>
>> Isn't the pitch and duration set by control panel parameters? It'd be
>> easy enough to hack the gs routine into a IIe ROM (if you don't
>> already use the self-test for other interesting things), but setting
>> the parameters is much harder.
>
>
> That shows you how little I use the IIgs! ;-)
>
> But since it's done by toggling the speaker, with a processor speed
> of 1MHz, it can certainly be generated on any Apple II.
I don't have a IIgs at hand to check the pitch of the "bonk", but
I've written a short routine that I think will produce the sound
on any Apple II.
The Merlin source, object, and an Applesoft test program are in
the archive:
http://home.comcast.net/~mjmahon/BONK.SHK
The test program loads the binary file, so you'll need to customize
the path to your own setup.
For some appropriate setting of the parameters, this should replicate
the IIgs "bonk". ;-)
This is still a test version, so the parameters are POKEd into the
routine, and a derivative parameter should be computed by the routine
instead of in the BASIC program, but it's a good sound test.
BTW, some emulators have a lot of trouble with high frequency PWM
and some handle it pretty well. A real Apple II should work best. ;-)
Michael J. Mahon
OK, I've just put up a somewhat more finished version. This one is
careful with the cycle counts, so it sounds a bit smoother.
I also decided to make zero page locations 06 and 07 be the parameters,
with 06 being the duration of a half-period of the generated tone in
samples (at 21.3kHz), and 07 being the number of tone cycles per volume
step (15 steps takes it from full volume to silence = end of sound).
The test program shows reasonable values--like 45 in location 06 and 2
in location 07, followed by CALL 768.
Michael J. Mahon
Mitchell Spector
Hmm, tried it on my Apple IIGS a moments ago (would have
tried it on the Apple IIc I rescued from a recycling center a few
weeks ago, but I just put it into storage with my other Apple II's).
Well, it's quite similar to the IIGS "bonk" yet not at all the
same. It still has that very distinctive Apple II speaker sound.
Difficult to describe, but I hear "Bonkzzzzzzt", "Bonkzzzzzt"
rather than a crisp and very defined "Bonk".
The more I listen to the GS's bell, the more I'm convinced
it's not something that can be reproduced on an Apple IIe.
Example, set the pitch in the Sound Control Panel to the
highest level. Try listening to it over and over, I've never
in all my years of Apple II gaming, programming and tinkering
heard a sound like that from the speaker (excluding, say,
digitized audio, though even then it wouldn't be as clear).
Mitchell Spector
Michael J. Mahon
I don't know what parameters you were using, but...
I just happened to get access to a IIgs this weekend.
The correct parameters for the default IIgs "bonk" are:
POKE 6,83
POKE 7,2
CALL 768
That reproduces it quite well. The volume is about 2/3 the max
volume of a raw beep, but the ear doesn't really care. ;-)
Mitchell Spector
>Mitchell Spector wrote:
>> Hmm, tried it on my Apple IIGS a moments ago (would have
>> tried it on the Apple IIc I rescued from a recycling center a few
>> weeks ago, but I just put it into storage with my other Apple II's).
>>
>> Well, it's quite similar to the IIGS "bonk" yet not at all the
>> same. It still has that very distinctive Apple II speaker sound.
>> Difficult to describe, but I hear "Bonkzzzzzzt", "Bonkzzzzzt"
>> rather than a crisp and very defined "Bonk".
>>
>> The more I listen to the GS's bell, the more I'm convinced
>> it's not something that can be reproduced on an Apple IIe.
>> Example, set the pitch in the Sound Control Panel to the
>> highest level. Try listening to it over and over, I've never
>> in all my years of Apple II gaming, programming and tinkering
>> heard a sound like that from the speaker (excluding, say,
>> digitized audio, though even then it wouldn't be as clear).
>
>I don't know what parameters you were using, but...
Parameters? All I did was download the Applesoft BASIC
program you wrote (the second revision) and ran it as-is on
my Apple IIc (managed to dig it out over the weekend and
had a listen). It runs through the sound scale from high to
low. I didn't play with any of the parameters.
>I just happened to get access to a IIgs this weekend.
>
>The correct parameters for the default IIgs "bonk" are:
>
>POKE 6,83
>POKE 7,2
>CALL 768
>
>That reproduces it quite well. The volume is about 2/3 the max
>volume of a raw beep, but the ear doesn't really care. ;-)
It's a similar approximation of the GS "bonk" bell (especially
the lower tones), but certainly not the same. :)
I'm still curious how the tone is produced. Maybe it's standard
speaker toggling that is then filtered or enhanced somehow using
something unique to the GS's audio circurity?
Mitchell Spector
Michael J. Mahon
> "Michael J. Mahon" <mjm...@aol.com> wrote:
>
>
>>Mitchell Spector wrote:
>>
>>> Hmm, tried it on my Apple IIGS a moments ago (would have
>>>tried it on the Apple IIc I rescued from a recycling center a few
>>>weeks ago, but I just put it into storage with my other Apple II's).
>>>
>>> Well, it's quite similar to the IIGS "bonk" yet not at all the
>>>same. It still has that very distinctive Apple II speaker sound.
>>>Difficult to describe, but I hear "Bonkzzzzzzt", "Bonkzzzzzt"
>>>rather than a crisp and very defined "Bonk".
>>>
>>> The more I listen to the GS's bell, the more I'm convinced
>>>it's not something that can be reproduced on an Apple IIe.
>>>Example, set the pitch in the Sound Control Panel to the
>>>highest level. Try listening to it over and over, I've never
>>>in all my years of Apple II gaming, programming and tinkering
>>>heard a sound like that from the speaker (excluding, say,
>>>digitized audio, though even then it wouldn't be as clear).
>>
>>I don't know what parameters you were using, but...
>
>
> Parameters? All I did was download the Applesoft BASIC
> program you wrote (the second revision) and ran it as-is on
> my Apple IIc (managed to dig it out over the weekend and
> had a listen). It runs through the sound scale from high to
> low. I didn't play with any of the parameters.
If you LISTed the program, you'd see that--like most sound routines--
the parameters are POKEd into page 0 prior to the CALL that actually
produces the sound.
At the time that I posted, I didn't have access to a IIgs, and
so didn't know what the actual frequency and duration of the
"bonk" was.
>>I just happened to get access to a IIgs this weekend.
>>
>>The correct parameters for the default IIgs "bonk" are:
>>
>>POKE 6,83
>>POKE 7,2
>>CALL 768
>>
>>That reproduces it quite well. The volume is about 2/3 the max
>>volume of a raw beep, but the ear doesn't really care. ;-)
>
>
> It's a similar approximation of the GS "bonk" bell (especially
> the lower tones), but certainly not the same. :)
Try POKEing the parameters I suggested and give it a listen.
After listening to them side by side, I'll bet it's the best
approximation that can be produced with Apple II hardware.
> I'm still curious how the tone is produced. Maybe it's standard
> speaker toggling that is then filtered or enhanced somehow using
> something unique to the GS's audio circurity?
The IIgs routine uses completely standard speaker toggling, combined
with linear decreases in speaker volume throughout the tone--which
only the IIgs hardware supports.
My routine does exactly the same thing, based on 21.3kHz pulse-width-
modulation. Many people (particularly those "of an age" ;-) cannot
hear the 21.3kHz pulses at all, but only the modulation, which is at
the "bonk" frequency. Ideally, one would use a low-pass filter to
remove all traces of the 21.3kHz "carrier", but we're trying to use
standard hardware...
I'm guessing that the primary difference is that on the IIgs, the
speaker is driven by an audio amplifier from the actual speaker toggle
logic level, while on all other Apple II's, the speaker is driven by
a Darlington driver with a peculiar AC-coupled, DC-clamped input.
The difference is increased when the toggling is low frequency.
The PWM approach assumes that the Apple II clock is constant
frequency, but that is not strictly true, since there is a stretched
cycle every horizontal line, or 62 cycles. This introduces a 15kHz
sub-cycle timing variation, causing an audible beat which is most
apparent under conditions of very low modulation (near silence).
The code I use to generate the "bonk" sound is:
**********************************************************
* *
* "Bonk" sound routine for Apple II *
* *
* Copyright Michael J. Mahon, 12/08/2009 *
* *
* Uses 21.3kHz PWM to synthesize a squarewave sound of *
* diminishing volume, mimicing the "bonk" IIgs sound. *
* *
* The PWM pulses are generated in 46-cycle loops, with *
* the high duty cycle pulses varying between 7 cycles *
* and 37 cycles, and the low duty cycle pulses always *
* 7 cycles. *
* *
* Sound generaton begins at maximum duty cycle (volume) *
* and diminshes by 1/15 on each volume step, until the *
* volume has been reduced to zero (equal high and low *
* duty cycle half-periods). *
* *
* Input parameters are: *
* 'hperiod' = Half-period of tone in 46-cycle samples *
* 'vperiods' = Tone (full) periods per volume step *
* *
* Since 15 volume steps are required to diminish the *
* volume to zero, the total sound duration is 15 times *
* 'vperiods' cycles of the generated tone. *
* *
**********************************************************
* Page zero data
hperiod equ $06 ; Half-period in samples (<129)
vperiods equ $07 ; Periods until vol step
vctr equ $08 ; Volume step counter
* Hardware definitions
SPKR equ $C030 ; Apple II speaker toggle
org $300
* Initialize
BONK lda #15 ; Init to 15 steps
sta vctr ; of dimishing volume.
lda #0 ; Init modified branches.
sta vinc+1
lda #hiduty-vdec-2 ; Point to hiduty
sta vdec+1
ldy hperiod ; Samples in half-period
dey ; minus 1.
tya ; Save half-period count.
ldx vperiods ; Countdown to volume step.
* Generate high duty-cycle half of squarewave
nop ; String of NOPs is target
nop ; of varying 'vdec' branch.
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
hidutym2 nop
hiduty sta SPKR ; Toggle speaker hi
vinc bpl *+2 ; <modified: 0..15> (always)
nop ; String of NOPs is target
nop ; of varying 'vinc' branch.
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
sta SPKR ; Toggle speaker lo
dey ; Count down half-period
vdec bpl hiduty ; <modified>
* Generate first low duty-cycle half cycle of squarewave
sta SPKR ; Toggle speaker hi
bpl *+2 ; (always)
sta SPKR ; Toggle speaker lo
dex ; Time to dec volume?
bne dnostep ; -No, delay then rejoin.
dec vctr ; -Yes, volume = zero?
beq return ; -Yes, return.
dec vdec+1 ; -No, decrease duty
inc vinc+1 ; cycle (volume).
ldx vperiods ; Reload vol step counter
nostep tay ; Reload half-period ctr
bne lodutym4 ; >0, gen more low pulses.
beq hidutym2 ; (always)
lodutym6 nop ; Kill 2 cycles
lodutym4 nop ; Kill 2 cycles
nop ; Kill 2 cycles
sta SPKR ; Toggle speaker hi
bpl *+2 ; (always)
sta SPKR ; Toggle speaker lo
jsr return ; Kill 12
jsr return ; Kill 12
dey ; Half-period expired?
bpl lodutym6 ; -No, keep looping.
tay ; -Yes, reset for hi loop
bpl hidutym2 ; (always)
dnostep jsr return ; Kill 18 cycles
nop
nop
nop
bne nostep ; and rejoin...
return rts
This code produces pulses in loops that are exactly 46 cycles long,
and varies the volume of the modulation by changing the "on" time
of the "high pulse" to the speaker from 37 cycles down to 7 cycles
in 15 steps of 2 cycles.
The parameters determine the audible frequency--the rate of switching
between the high duty cycle and the low duty cycle--and the number of
(audible) periods between decrements in volume.
Mitchell Spector
>Mitchell Spector wrote:
>> "Michael J. Mahon" <mjm...@aol.com> wrote:
>>>The correct parameters for the default IIgs "bonk" are:
>>>
>>>POKE 6,83
>>>POKE 7,2
>>>CALL 768
>>>
>>>That reproduces it quite well. The volume is about 2/3 the max
>>>volume of a raw beep, but the ear doesn't really care. ;-)
>>
>> It's a similar approximation of the GS "bonk" bell (especially
>> the lower tones), but certainly not the same. :)
>
>Try POKEing the parameters I suggested and give it a listen.
Not sure if this is what you're suggesting, but here's what I did:
-Loaded your "Test.bonk" program into memory and ran it once
-Typed in 'CALL 768' and heard one tone only
-Typed in POKE 6,83 <return>, POKE 7,2 <return>
-Typed in 'CALL 768' once again, heard a lower tone this time
>After listening to them side by side, I'll bet it's the best
>approximation that can be produced with Apple II hardware.
It's closer in pitch, but still not the very unique IIgs "bonk".
Using the different parameters (assuming I used them correctly)
got something closer, but still not exact.
>> I'm still curious how the tone is produced. Maybe it's standard
>> speaker toggling that is then filtered or enhanced somehow using
>> something unique to the GS's audio circurity?
>
>The IIgs routine uses completely standard speaker toggling, combined
>with linear decreases in speaker volume throughout the tone--which
>only the IIgs hardware supports.
>
>My routine does exactly the same thing, based on 21.3kHz pulse-width-
>modulation. Many people (particularly those "of an age" ;-) cannot
>hear the 21.3kHz pulses at all, but only the modulation, which is at
>the "bonk" frequency. Ideally, one would use a low-pass filter to
>remove all traces of the 21.3kHz "carrier", but we're trying to use
>standard hardware...
>
>I'm guessing that the primary difference is that on the IIgs, the
>speaker is driven by an audio amplifier from the actual speaker toggle
>logic level, while on all other Apple II's, the speaker is driven by
>a Darlington driver with a peculiar AC-coupled, DC-clamped input.
Ahh. If that's the case, then the "bonk" sound on Apple IIGS,
through which ever method or means it is produced, is unique to
the IIGS and cannot be reproduced identically on an 8-bit Apple II.
Which brings up something interesting that I've always thought
about. It seems like there's this untapped sound capability on the
IIGS which is neither emulated Apple II speaker toggling OR the
Ensoniq synthesizer. Call it enhanced speaker toggling if you will. :)
Apart from the system bell, I've never seen a single programmer
experiment or use this sound feature in any piece of software.
I've seen speaker toggling used in native IIGS software for audio
(e.g. Paperboy, Gauntlet, John Madden's Football) but is it just old
fashioned 8-bit Apple II sound. I wonder if some kind of simple music
program could be written that could use it...just for the sake of
seeing if it could be done. The most simple thing to try would be
to play any of the Control Panel bell pitches at will, like a piano
keyboard! This would be running on a IIgs of course, we're talking
about just playing the pitches in the Sound Control Panel.
Mitchell Spector
Michael J. Mahon
> "Michael J. Mahon" <mjm...@aol.com> wrote:
>
>
>>Mitchell Spector wrote:
>>
>>>"Michael J. Mahon" <mjm...@aol.com> wrote:
>>>
>>>>The correct parameters for the default IIgs "bonk" are:
>>>>
>>>>POKE 6,83
>>>>POKE 7,2
>>>>CALL 768
>>>>
>>>>That reproduces it quite well. The volume is about 2/3 the max
>>>>volume of a raw beep, but the ear doesn't really care. ;-)
>>>
>>> It's a similar approximation of the GS "bonk" bell (especially
>>>the lower tones), but certainly not the same. :)
>>
>>Try POKEing the parameters I suggested and give it a listen.
>
>
> Not sure if this is what you're suggesting, but here's what I did:
>
> -Loaded your "Test.bonk" program into memory and ran it once
> -Typed in 'CALL 768' and heard one tone only
> -Typed in POKE 6,83 <return>, POKE 7,2 <return>
> -Typed in 'CALL 768' once again, heard a lower tone this time
That's it!
>>After listening to them side by side, I'll bet it's the best
>>approximation that can be produced with Apple II hardware.
>
>
> It's closer in pitch, but still not the very unique IIgs "bonk".
> Using the different parameters (assuming I used them correctly)
> got something closer, but still not exact.
I had a IIgs and my //e side by side and put each into a loop
doing the IIgs "native" bonk and my //e bonk about once a second.
I adjusted the parameters to get the closest match, and it seemed
right in pitch, duration, and envelope.
If both waveforms are squarewaves with linearly diminishing
amplitudes, that should do it.
Is the IIgs volume control non-linear? That is, is volume 14 twice
the amplitude of volume 7? It's possible that the IIgs volume control
is a non-linear pot, but unusual.
>>> I'm still curious how the tone is produced. Maybe it's standard
>>>speaker toggling that is then filtered or enhanced somehow using
>>>something unique to the GS's audio circurity?
>>
>>The IIgs routine uses completely standard speaker toggling, combined
>>with linear decreases in speaker volume throughout the tone--which
>>only the IIgs hardware supports.
>>
>>My routine does exactly the same thing, based on 21.3kHz pulse-width-
>>modulation. Many people (particularly those "of an age" ;-) cannot
>>hear the 21.3kHz pulses at all, but only the modulation, which is at
>>the "bonk" frequency. Ideally, one would use a low-pass filter to
>>remove all traces of the 21.3kHz "carrier", but we're trying to use
>>standard hardware...
>>
>>I'm guessing that the primary difference is that on the IIgs, the
>>speaker is driven by an audio amplifier from the actual speaker toggle
>>logic level, while on all other Apple II's, the speaker is driven by
>>a Darlington driver with a peculiar AC-coupled, DC-clamped input.
>
>
> Ahh. If that's the case, then the "bonk" sound on Apple IIGS,
> through which ever method or means it is produced, is unique to
> the IIGS and cannot be reproduced identically on an 8-bit Apple II.
I haven't done the experiment, but I suspect that using ultrasonic
PWM prevents the "standard" Apple II sound from being affected much
by the coupling circuit. This might justify some 'scope observations
as well as comparative listening tests (for different ways of producing
squarewave sounds on a //e).
The most unusual feature of the IIgs is a program-controlled volume
control on the speaker. This can be used to greatly increase the
dynamic range of sounds while still preserving PWM signal to noise
ratio.
> Which brings up something interesting that I've always thought
> about. It seems like there's this untapped sound capability on the
> IIGS which is neither emulated Apple II speaker toggling OR the
> Ensoniq synthesizer. Call it enhanced speaker toggling if you will. :)
> Apart from the system bell, I've never seen a single programmer
> experiment or use this sound feature in any piece of software.
>
> I've seen speaker toggling used in native IIGS software for audio
> (e.g. Paperboy, Gauntlet, John Madden's Football) but is it just old
> fashioned 8-bit Apple II sound. I wonder if some kind of simple music
> program could be written that could use it...just for the sake of
> seeing if it could be done. The most simple thing to try would be
> to play any of the Control Panel bell pitches at will, like a piano
> keyboard! This would be running on a IIgs of course, we're talking
> about just playing the pitches in the Sound Control Panel.
Check out RT.SYNTH. It doesn't (yet?) include a damped squarewave,
but that would be a trivial addition--with any envelope. (Of course,
it's still 5-bit samples.)
If a damped squarewave was all that was desired, then the native IIgs
bonk routine approach (see Jerry's post) could be used, though it would
take significant re-work to get accurate musical notes.
vladitx
> I'm guessing that the primary difference is that on the IIgs, the
> speaker is driven by an audio amplifier from the actual speaker toggle
> logic level, while on all other Apple II's, the speaker is driven by
> a Darlington driver with a peculiar AC-coupled, DC-clamped input.
I never investigated this, by there is very audible asymmetry in each
toggle direction. Some day ... yep, definitely.
> The PWM approach assumes that the Apple II clock is constant
> frequency, but that is not strictly true, since there is a stretched
> cycle every horizontal line, or 62 cycles.
65, I know it's a typo. :-)
> This introduces a 15kHz
> sub-cycle timing variation, causing an audible beat which is most
> apparent under conditions of very low modulation (near silence).
Surely you have tried PWM at 15.7 kHz (65 cycles), where no modulation
occurs, just slightly inaccurate PWM. Is the carrier that noticeable?
Michael J. Mahon
> On Dec 23, 4:58 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
>>I'm guessing that the primary difference is that on the IIgs, the
>>speaker is driven by an audio amplifier from the actual speaker toggle
>>logic level, while on all other Apple II's, the speaker is driven by
>>a Darlington driver with a peculiar AC-coupled, DC-clamped input.
>
>
> I never investigated this, by there is very audible asymmetry in each
> toggle direction. Some day ... yep, definitely.
>
>
>>The PWM approach assumes that the Apple II clock is constant
>>frequency, but that is not strictly true, since there is a stretched
>>cycle every horizontal line, or 62 cycles.
>
>
> 65, I know it's a typo. :-)
;-)
>> This introduces a 15kHz
>>sub-cycle timing variation, causing an audible beat which is most
>>apparent under conditions of very low modulation (near silence).
>
>
> Surely you have tried PWM at 15.7 kHz (65 cycles), where no modulation
> occurs, just slightly inaccurate PWM. Is the carrier that noticeable?
When I was younger, it would have driven me from the room!
Today, I probably wouldn't notice it. ;-)
More seriously, I think that many users would find it quite audible,
making it necessary to low-pass the audio, which would greatly
reduce the fraction of people who could practically use it.
My first DAC ran at 11.05kHz, and even that frequency was barely
audible to me--but it drove the rest of my family crazy! It had
the advantage of allowing 6-bit conversion (64 pulse widths), but
the necessity of low-pass filtering the output seemed too great
a sacrifice in usability.
I've never built a software DAC running at 15.7kHz, partly because
using it would require resampling all the sound files out there, most
of which are at 11.05kHz. It would be pretty easy to try, and the
extra 19 cycles would certainly be useful. ;-)
One downside is that the maximum variation in pulse width would still
have to be 32 cycles, since 64 is unattainable in a 65-cycle loop,
and any other choice results in unequal steps. The effect would be
a reduction in maximum volume by 46/65.
BTW, there would not be significant PWM inaccuracy, since the
stretched cycle would always occur at the same point in the loop,
causing only a slight nonlinearity in transfer function, but no
beat frequency. (If the nonlinearity really mattered, it would
be possible to "vapor lock" to horizontal blanking so that the
stretched cycle always occurred in a non-pulse-producing part
of the loop.)
Mitchell Spector
>Mitchell Spector wrote:
>> "Michael J. Mahon" <mjm...@aol.com> wrote:
>> It's closer in pitch, but still not the very unique IIgs "bonk".
>> Using the different parameters (assuming I used them correctly)
>> got something closer, but still not exact.
>
>I had a IIgs and my //e side by side and put each into a loop
>doing the IIgs "native" bonk and my //e bonk about once a second.
>I adjusted the parameters to get the closest match, and it seemed
>right in pitch, duration, and envelope.
Well, using a hardware IIGS.... immediately after doing the 'CALL
768' and listening, invoke the system bell with a CTRL-G. Do you
hear how different the native bonk is? :)
So I take it you cannot reproduce the IIGS bonk on an Apple II,
II+, IIe, IIc or IIc+ with 100% accuracy?
>> I've seen speaker toggling used in native IIGS software for audio
>> (e.g. Paperboy, Gauntlet, John Madden's Football) but is it just old
>> fashioned 8-bit Apple II sound. I wonder if some kind of simple music
>> program could be written that could use it...just for the sake of
>> seeing if it could be done. The most simple thing to try would be
>> to play any of the Control Panel bell pitches at will, like a piano
>> keyboard! This would be running on a IIgs of course, we're talking
>> about just playing the pitches in the Sound Control Panel.
>
>Check out RT.SYNTH. It doesn't (yet?) include a damped squarewave,
>but that would be a trivial addition--with any envelope. (Of course,
>it's still 5-bit samples.)
>
>If a damped squarewave was all that was desired, then the native IIgs
>bonk routine approach (see Jerry's post) could be used, though it would
>take significant re-work to get accurate musical notes.
I've played with RT.SYNTH on my 8-bit Apple II's, it amazes me
how far you can push the internal speaker!
I was thinking of something unrelated though. The 15 pitches in
the Sound Control Panel, they can only be played sequentially (+1 or
-1) in scale. I thought it'd be fun to program something where you
can play ANY of the 15 pitch tones at will (e.g. pitch 3, 8, 7, 15, 4).
Is there a way to access the Control Panel Sound's pitch and
change it arbitrarily on the fly? Actually, I seem to remember this
is what the graphical Control Panel in System 6 allows, but I'd
want to assign each pitch to a key press, much like RT.SYNTH.
It's interesting how the IIGS bonk is completely reproduceable
in an emulator, like KEGS (apart from a slight click or pop at the
end). If you look at how that is done, it would reveal any of the
mystery here.
Mitchell Spector
Michael J. Mahon
> "Michael J. Mahon" <mjm...@aol.com> wrote:
>
>
>>Mitchell Spector wrote:
>>
>>>"Michael J. Mahon" <mjm...@aol.com> wrote:
>>> It's closer in pitch, but still not the very unique IIgs "bonk".
>>>Using the different parameters (assuming I used them correctly)
>>>got something closer, but still not exact.
>>
>>I had a IIgs and my //e side by side and put each into a loop
>>doing the IIgs "native" bonk and my //e bonk about once a second.
>>I adjusted the parameters to get the closest match, and it seemed
>>right in pitch, duration, and envelope.
>
>
> Well, using a hardware IIGS.... immediately after doing the 'CALL
> 768' and listening, invoke the system bell with a CTRL-G. Do you
> hear how different the native bonk is? :)
>
> So I take it you cannot reproduce the IIGS bonk on an Apple II,
> II+, IIe, IIc or IIc+ with 100% accuracy?
Well, since case size, speaker mounting, etc., all have some influence
on the actual sound, I think it's a better question whether the sound
can be produced on a IIgs without using the hardware volume control.
Because of fundamental limitations in the production of sound and the
insensitivity of the human ear to absolute sound levels, I also think
that producing the sound at a somewhat lower volume should still count
as a faithful reproduction of the sound.
So my particular routine may have some deficiencies (in parasitic
noise, duration resolution, etc.), but a similar routine could come
"close enough for all practical purposes". ;-)
>>> I've seen speaker toggling used in native IIGS software for audio
>>>(e.g. Paperboy, Gauntlet, John Madden's Football) but is it just old
>>>fashioned 8-bit Apple II sound. I wonder if some kind of simple music
>>>program could be written that could use it...just for the sake of
>>>seeing if it could be done. The most simple thing to try would be
>>>to play any of the Control Panel bell pitches at will, like a piano
>>>keyboard! This would be running on a IIgs of course, we're talking
>>>about just playing the pitches in the Sound Control Panel.
>>
>>Check out RT.SYNTH. It doesn't (yet?) include a damped squarewave,
>>but that would be a trivial addition--with any envelope. (Of course,
>>it's still 5-bit samples.)
>>
>>If a damped squarewave was all that was desired, then the native IIgs
>>bonk routine approach (see Jerry's post) could be used, though it would
>>take significant re-work to get accurate musical notes.
>
>
> I've played with RT.SYNTH on my 8-bit Apple II's, it amazes me
> how far you can push the internal speaker!
And I think you'd agree that it doesn't sound like "old fashioned 8-bit
Apple II sound"!
> I was thinking of something unrelated though. The 15 pitches in
> the Sound Control Panel, they can only be played sequentially (+1 or
> -1) in scale. I thought it'd be fun to program something where you
> can play ANY of the 15 pitch tones at will (e.g. pitch 3, 8, 7, 15, 4).
> Is there a way to access the Control Panel Sound's pitch and
> change it arbitrarily on the fly? Actually, I seem to remember this
> is what the graphical Control Panel in System 6 allows, but I'd
> want to assign each pitch to a key press, much like RT.SYNTH.
This should actually be quite easy for someone to do, subject to the
limitation that the sounding of one note cannot be interruped by the
sounding of another. (In other words, each "bonk" must be allowed to
play to completion.)
> It's interesting how the IIGS bonk is completely reproduceable
> in an emulator, like KEGS (apart from a slight click or pop at the
> end). If you look at how that is done, it would reveal any of the
> mystery here.
The only mystery remaining is the absolute value of successive volume
steps (a IIgs hardware characteristic). Everything else about the
"bonk" is well understood (see Jerry's posting of the code that
produces it).
vladitx
> vladitx wrote:
> > Surely you have tried PWM at 15.7 kHz (65 cycles), where no modulation
> > occurs, just slightly inaccurate PWM. Is the carrier that noticeable?
>
> When I was younger, it would have driven me from the room!
> Today, I probably wouldn't notice it. ;-)
I did quite of PWM on the PC's speaker with carriers in the audible
range, and can't remember being that repulsive. Maybe the magic of the
"useful" 6-bit sound helped (for me), compared to the usual bleeps.
By the way, the 15.7 kHz freq may be already heard from the CRT, so
the listeners should be trained to ignore it to a certain extent. :)
> I've never built a software DAC running at 15.7kHz, partly because
> using it would require resampling all the sound files out there, most
> of which are at 11.05kHz. It would be pretty easy to try, and the
> extra 19 cycles would certainly be useful. ;-)
There are command-line tools to do batch resampling for you, like this
one:
> One downside is that the maximum variation in pulse width would still
> have to be 32 cycles, since 64 is unattainable in a 65-cycle loop,
> and any other choice results in unequal steps. The effect would be
> a reduction in maximum volume by 46/65.
If you still decide to give it a try, keep us posted. This sacrifice
is interesting to me at least.
> BTW, there would not be significant PWM inaccuracy, since the
> stretched cycle would always occur at the same point in the loop,
> causing only a slight nonlinearity in transfer function, but no
> beat frequency.
Exactly what I was implying. ;-)
Michael J. Mahon
> On Dec 23, 11:56 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>>vladitx wrote:
>>
>>>Surely you have tried PWM at 15.7 kHz (65 cycles), where no modulation
>>>occurs, just slightly inaccurate PWM. Is the carrier that noticeable?
>
>>When I was younger, it would have driven me from the room!
>>Today, I probably wouldn't notice it. ;-)
>
> I did quite of PWM on the PC's speaker with carriers in the audible
> range, and can't remember being that repulsive. Maybe the magic of the
> "useful" 6-bit sound helped (for me), compared to the usual bleeps.
Perhaps the PC speaker and mounting was not very responsive to
such high frequencies, serving as a _de facto_ lowpass filter.
I've never measured the Apple II speaker response, but when I
was testing PWM DACs, both my wife and my daughters complained
mightily from the next room (!) when I tested the 11kHz versions. ;-)
> By the way, the 15.7 kHz freq may be already heard from the CRT, so
> the listeners should be trained to ignore it to a certain extent. :)
Good point--though many people find that quite annoying if it
is loud.
>>I've never built a software DAC running at 15.7kHz, partly because
>>using it would require resampling all the sound files out there, most
>>of which are at 11.05kHz. It would be pretty easy to try, and the
>>extra 19 cycles would certainly be useful. ;-)
>
>
> There are command-line tools to do batch resampling for you, like this
> one:
>
> http://sox.sourceforge.net/
Right--it's easy to do with the right tools, in fact SOUND.EDITOR will
resample on the Apple II. But I wanted a program that could directly
play and manipulate the huge store of 11kHz sampled sounds, rather
than requiring users to do extra steps.
>>One downside is that the maximum variation in pulse width would still
>>have to be 32 cycles, since 64 is unattainable in a 65-cycle loop,
>>and any other choice results in unequal steps. The effect would be
>>a reduction in maximum volume by 46/65.
>
>
> If you still decide to give it a try, keep us posted. This sacrifice
> is interesting to me at least.
I'm going to try it out. Particularly for Crate.Synth, since the
AppleCrate II audio system has good lowpass filtering, and 15kHz
shouldn't be a problem for it. In fact, 11kHz might also be OK... ;-)
I'm away from the AppleCrate II for a few months, but I can do some
preliminary work on the assumption that the filtering will be adequate.
>>BTW, there would not be significant PWM inaccuracy, since the
>>stretched cycle would always occur at the same point in the loop,
>>causing only a slight nonlinearity in transfer function, but no
>>beat frequency.
>
>
> Exactly what I was implying. ;-)
We're on the same page. ;-)