The faster you tweak the speaker, the higher the pitch. So I tried to generate
the highest pitch possible:
l1 sta $c030 ; tweak the speaker
jmp l1
When run, it makes no noise. Well, almost no noise. You can hear a faint
whine from the speaker. What happens is that you can pop the speaker back
into one position before it reaches the other from the last pop, damping the
sound. A little tweaking gave me a software volume control by putting to
tweaks close together with a balanced timing loop:
sta $c030
l1 ldy #$01
l2 dey
bne l2
sta $c030
l3 ldy #$07
l4 dey
bne l4
The trick was equalizing the delay, so you self-modify the code before you
start playing sound (since ldy with an absolute address used 2 more cycles
than a ldy immediate):
lda volume
and #$7
sta l1+1 ; self-modify the preceding loops
tay
lda compliment,y ; get the compliment of the volume
sta l3+1
volume hex 01
compliment
hex 01020304050607
Which now gave you a way to generate up to 7 volumes. But wait, there's more!
The "standard" way of generating sound was to click the speaker, run a delay
loop then loop back. This would give you a simple square wave with a problem
that higher frequencies had shorted durations than lower frequencies, since
the duration was partially dependent on how long your delay was. Bogus!
My solution was have one outside loop and click the speaker every nth time
through the loop (which also gave finer frequency control). This meant that
most of my time wasn't spent running a delay, but instead skipping over the
speaker click. This allowed me to nest two separate speaker click routines
allowing two different voices with independent volume control.
It also turned out that I could do all this using only the A and Y registers and
that left me with the X register for something else... hmm, what can I do now?
I know! Attack and decay! Of course, with all of this added in the frequency
values were not quite linear, ie, doubling the frequency value didn't *quite*
double the generated frequency. I never quite found my way around that one...
Then again, I was only 15 at the time.
I moved on to other things, like writing a digitizer that used the cassette
input port and used every available sector on the disk (including that one
track you could only get to by modifying the cmp #$23 instruction in RWTS
before you initialized the disk), and then writing a playback program that
loaded the largest hunks it could get off of disk at once (about 40K) and
play them back. This amounted to about 2 minutes of sound. I got thrown
out of the school library by setting it up to continuosly play Eruption by
Eddie Van Halen...
*sigh* I miss my salad days sometimes...
Have you ever noticed that nostalgia just isn't what it used to be?
Steve Hawley
haw...@adobe.com
--
"Did you know that a cow was *MURDERED* to make that jacket?"
"Yes. I didn't think there were any witnesses, so I guess I'll have to kill
you too." -Jake Johansen
>Speaking of Apple II sounds, I have a question for you old gurus out there :)
>If you've ever played Archon, you know the opening sequence music; it's a
>pretty impressive piece IMHO. Now, why on earth did all other games have such
>bad sound? Was it just hard to program in Apple's DOS?
I think it was partly that there was no established standard for sound
generation, it being somewhat arcane for sounds more than relatively
pure tones. Not all other games had bad sound, either. The noisiest
game with the best sound effects was probably Vindictor (H.A.L. Labs).
As for music, as in Archon (wasn't that a James Nitchals port?), I
seem to recall that Paul Lutus (Musicomp, GraFORTH, Apple Writer,
among others) wrote a two-voice music generation program (title eludes
me) that paved the way for more complicated sounds on the Apple II.
There were whole whole diskettes of nothing but music... for a typical
example of its use in a game, take a peek at Bruce Lee (Datasoft). I
bet it took a bit of processing time to do the two-voice stuff, which
would preclude its use during animated graphics.
subLogic also had a program called Music Maker (I think) which could
generate richer tones than a program like Musicomp, but didn't do
multiple voices. Hmm. Were there ever Mockingboard emulators for
Apple-Cats?
Ah, history...
> julius yang |. .| [tybalt-1]% rm /usr/home/julius/brain/* |. .|
>jul...@tybalt.caltech.edu | _ | [tybalt-2]% | _ |
--
Dwight A Lee / l...@chsun1.uchicago.edu / T90...@niucs.BITNET / tCS/BB / Font
I speak only for myself. / "I am not the only dust my mother raised" - TMBG
>jul...@nntp-server.caltech.edu (julius yang) writes:
>As for music, as in Archon (wasn't that a James Nitchals port?)
Yup. He did a few other games that had great sound. One was a maze-type
game, for the life of me I can't remember the name of it. This _was_ >7
years ago, you know... It has something to do with radiation I think.
Oh, I remember now, it was called _Microwave_. I think you cooked your
enemies with a beam of some kind... :-)
>subLogic also had a program called Music Maker (I think) which could
>generate richer tones than a program like Musicomp, but didn't do
>multiple voices.
I think Music Maker did. You really didn't have a lot of control over
timbre, but most everything else including volume.
On the topic of sound, nobody has mentioned that Apple actually published
some routines to make sound as far back as, say, 1978. Remember
Programmer's Aid #1? This was a ROM you could install on the Autostart ROM
board, or maybe directly on the actual original Integer Basic motherboard.
There were a library of routines, including Hires graphics for people that
actually wrote in integer basic. I believe the routines are still around,
I remember them being included in the INTEGER binary image that came on the
old DOS 3.3 disks. The routines were just machine lanuage calls, with
values poked somewhere in the $300 page I think.
>Ah, history...
I know. (sigh) I cut my teeth on an Apple II back in fourth grade...
The serial # was in the low thousands, 4K RAM, everything was loaded off of
cassettes, and those awful paddle controls! Anyone remember Star Wars?
Louis Koziarz
University of Illinois at Urbana/Champaign
koz...@uiuc.edu
>Loading from the speaker location and writing to the speaker location
>gave two different sounds. The speaker was "clicked" every time the
>memory location was referenced. But since the 6502 actually *read* the
>contents of a memory location before *writing* the new value out to it,
>it referenced that location twice (producing two clicks for a write, and
>one click for a read).
Huh? I thought it would click every other time you referenced it with a
read, but every time when you did a write. I believe I read that in
Assembly Lines: The Book, by Roger Wagner. Unfortunately I don't have the
book handy right now.
--
/// ____ \\\ "It says, `Golgafrincham Ark Fleet, Ship B, Hold 7, Telephone
| |/ / \ \| | Sanitizer, Second Class,' and a serial number." "A telephone
\\_(\____/)_// sanitizer? A dead telephone sanitizer?" "Best
greg \_\\\/ hoss.unl.edu kind." "But what's he doing here?" "Not a lot."
but you forgot to mention MY favorite bit of apple II sound trivia.
Loading from the speaker location and writing to the speaker location
gave two different sounds. The speaker was "clicked" every time the
memory location was referenced. But since the 6502 actually *read* the
contents of a memory location before *writing* the new value out to it,
it referenced that location twice (producing two clicks for a write, and
one click for a read).
I, too, played with the sounds my apple II could make and am very
impressed with all the refinements mentioned in the previous article.
I would like to mention one additonal refinement that can have a lot to
do with the quality of sound that that little speaker could put out.
Different instructions (LDA, STA, BNE...) were executed in a different
number of machine cycles. By changing the instrucions in a loop, it is
possible to change the characteristics of the sound from the speaker.
I'll bet this is the way you could even out the length/pitch/attack,delay
problems mentioned earlier.
>Yup. He did a few other games that had great sound. One was a maze-type
>game, for the life of me I can't remember the name of it. This _was_ >7
>years ago, you know... It has something to do with radiation I think.
>Oh, I remember now, it was called _Microwave_. I think you cooked your
>enemies with a beam of some kind... :-)
Yes, Microwave! Great game, great sound, great opening sequence! And a
rather tricky game; I never could get past the fourth maze or so, and even
that was a rare achievement.
What became of Nitchals?
--
Kevin Martin
si...@ipl.rpi.edu
"I am NOT a Merry Man!"
I kick myself now because that original Apple II my high school
had came with an Apple Red Book, which I had on long-term loan to
myself but eventually returned. Now I think I should have kept
it.
The Apple Red Book had an early Paul Lutus sound routine which
was true art. I ended up duplicating much of the work others
have described--frequency-based sound generators (count down a
timer then click the speaker), wavelength-based generators (click
the speaker every N times through a constant-time loop),
loudness, timbre control with a rotating bit mask, and so on. I
saw the Paul Lutus routine, and once I had analyzed its timing
characteristics, I was amazed. It was of the type I'd call a
wavelength-based generator, but much smaller than anything I'd
ever come up with. It sacrificed a little bit of timing
consistency (my routines were at least 100% rock-solid in their
timing) to get a much shorter wavelength quantum, meaning it
could get much better resolution at higher pitches.
Ah, and then there was my Life program that eventually grew to
running on 256 X 256 arrays with a 96 X 96 scrollable display
window, at about 50 generations per minute (typical). I spent
months bumming the display routine, which would build hi-res
bytes directly out of the Life arrays, and translated a bit of
PDP-11 assembler published in a BYTE article that did addition on
words in parallel, only to discover that it had severe typos so
that I had to re-derive their algorithm.
But perhaps the nostalgia gets too thick.
--
Steve VanDevender ste...@greylady.uoregon.edu
"Bipedalism--an unrecognized disease affecting over 99% of the population.
Symptoms include lack of traffic sense, slow rate of travel, and the
classic, easily recognized behavior known as walking."
dd 11 22 33 44
Where "dd" was the note duration, and the bytes following were note numbers
(even numbers only). This gave a scale running from C1 to C4, mostly in tune.
I actually went so far as to arrange a couple of Christmas carols for it.
I accidentally saved the BASIC program and forgot to save the machine
language section once; this left weird things lying around in the memory
that the program proceeded to interpret as if they were actual "songs".
Very strange noises resulted...
------------------------- Original Article -------------------------
The Apple II, like an unmodified IBM-PC clone, has a one-bit sound register.
All the computer can do is either apply or remove 5 volts on the speaker
wires. This produces a "click". By clicking really fast, sound is made in
various frequencies. Always in a square wave, though. All "good" sound on
those machines has to be done by frequency modulating the sound. A two
or three-track square-only synthesizer could be done this way, but it
will eat every processor cycle. For an example, see either "The Electronic
Duet" for the Apple II series or VMUSIC.COM for the IBM-PC. VMUSIC will
do three channels and is shareware. The Electronic Duet is older, and can
only do two channels. A run-time form of it was used to produce the
"Sonata" program that comes on a demo disk with the Apple //c (at least
it came with mine)
--
David Charlap "Invention is the mother of necessity"
cd5...@mars.njit.edu "Necessity is a mother"
Operators are standing by "mother!" - Daffy Duck
Actually, this isn't true -- two voices will not eat every CPU cycle. In fact,
they leave an ample number of cycles to spare for doing a modicum of graphics
work on the Apple II. If you have no bells and whistles, just two simple
multiplexed square waves, and modify the main loop so that it carries enough
state so that it can run a bit then exit and be ready to restart, it's easy to
interleave a few screen updates.
A friend of mine was wote the game Falcons (a Phoenix clone) for the Apple and
didn't put bother with the music because he didn't think it could be done. It
turns out he was right, in that it couldn't be done in the context of something
as complicated as Phoenix, but I wrote a tiny shoot-em up that featured a
ship for the player and 6 opponents that played Fur Elise in two voices while
you you blasted them to bits (or vice versa). The sound was not hi-fi by any
definition of the word, but it was do-able. I did this mostly to annoy him.
It worked.
The Electronic Duet by Paul Lutus was a gem of a program. His playback program
did some screen hack animation while the music was playing. That impressed me
because he was doing two voices with distinct *timbres* (each voice could have
one of 4 (?) timbres).
> Apple II sound programming got me started on machine-language
> programming. I really did start with machine-language
> programming--armed with a 6502 reference and my naivete, I would
Gush.
I traipsed from Z80 (Trash-80, of course) over to an Apple ][+ [Wizardry
forced me to do it!], and eventually, after defeating the evil Werdna, I
decided that there must be something else to this damn computer.
So I fiddled with programming for the beast. Basic was just too slow [and
awful] to play with for too long. Doing lissajous figures, and moire patterns
on the kludgy screens bored me to tears, and was so SLOW.
I then read an article in some rag [A+ or Incider] that detailed how to
'digitise' sound with the cassette port. I coded the thing, and it even
worked! Playing 30 seconds worth of 'Blue Oyster Cult' out of the Apple's
speaker was just amazing!
Then I thought of 'analyzing' the sound, and doing graphics for it. Lores
graphics came into play, and I spent many an night coding away, unrolling
loops to get more speed. Eventually I had a dynamic display that was quite
spectacular [with decent music like 'The Wall' - anything with less dynamic
range tended to produced a boring display].
Always seeking a better assembler [the ][+ didn't have the Integer rom!] I was
using something that compiled really fast, but had this 40 column rubbish to
contend with. Putting comments in was a major chore, that I used to forgo,
and then forget what a routine was doing. Major karmic loss as I cursed and
swore and had to bit-twiddle in my head to work it out [my TI calculator blew
up :-(]
I even tried going back to Z80 with a 6Mhz Z80B card, but it just wasn't easy
playing with hi-res screens that weren't contiguous. I still have my Sirius
Accellerator (3.6Mhz 6502), and the Apple lives in Tasmania, where it's on
permanent loan to a Wizardry fanatic friend. :-)
My Amiga is lots better than a wormy old Apple. :-)
Dac
--
SLO - ASL,ORA RLA - ROL,AND LSE - LSR,EOR RRA - ROR,ADC
DCP - DEC,CMP ISC - INC,SBC LXA - LDA,LDX
SAX - Store result of A AND X
SBX - X <- (X AND A) - data (doesn't read C, but does change it)
XAN - A <- X AND data
RAR - ROR A
ROR #$-- (2)
AND #$--
STR - Mem <- A AND X AND (high byte of addr +1) (7)
LAX - LDA #$-- (1)
TAX
SAM - TSA (3)
AND mem
TAS (4)
TAX
XAM - Mem <- X AND (high byte of addr +1) (7)
ALC - AND #$--
ASL A (5)
SAR - LSR A
LSR #$-- (2)
AND #$--
SRS - ANX (6)
TXS
STR $----,Y
YAM - Mem <- Y AND (high byte of addr +1) (7)
(1) If the previous LSB of each nybble of A is 0, the nybble in the
loaded value is ANDed with $E
(2) The immediate operand is shifted prior to the AND, but the
instruction in memory is not changed
(3) Transfer stack pointer to A
(4) Transfer A to stack pointer
(5) Bit 7 is moved to the C flag, but A is not changed
(6) The result of A AND X is loaded into X
(7) Addr is calculated by
addr = ---- + Y (or X, depending on instr)
If page boundary is crossed, then AND high byte with X (or Y)
This is the list I came up with 4 or 5 years ago. I'm pretty certain its
correct, but... Anyone with a logic analyser or the microcode listing
want to check? The timing is a little more dubious (but a lot less
useful). I'm not sure why some of those NOPs are taking so long.
And yes, I have used some of these instructions. SBX has proved a
life-saver at times. ALC is good as part of a 2-instruction 'Arithmetic
shift right' (ALC,ROR)
Bye for now.
John West (stealing Andrew's account)
Are you a fish?
> I then read an article in some rag [A+ or Incider] that detailed how to
> 'digitise' sound with the cassette port. I coded the thing, and it even
> worked! Playing 30 seconds worth of 'Blue Oyster Cult' out of the Apple's
What issue of A+ or Incider is this? I am quite interested in reading more
about it. I own an Apple ][+, and it is quite the antediluvian baby now,
isn't it? Anyway, I still have sentimental attachments to it. Any help on
hacking with the speaker would be great. Thanks!
--RpC
----------------------------------------------------------------
Rangsarn Chanyavanich
BITNET: SRCHAN@MACALSTR
INTERNET: SRC...@MAC.CC.MACALSTR.EDU, SRC...@MACALSTR.EDU
Macalester College
St. Paul, MN 55105-1801
----------------------------------------------------------------
Well, to record digital samples, the joystick/paddle port is your best
bet. It is your only analog input device. You can get 8-bit resolution
samples by plugging a dynamic microphone across a paddle port and insert a
few resistors to match the impedance to the range the Apple expexts a
joystick to be (I think it's 150K-Ohms). Now, by polling the joystick
port rapidly (you'll need assembply language to do it fast enough), you
can record the samples.
Playback is more difficult. The Apple has no analog output other than the
video connector. You _CAN_ make a simple card to plug into a slot with
an 8-bit D-A converter on it. This will take your samples and play them.
(Hook the output of the D/A converter to an amplifier). The other way is
to frequency modulate the sound to square waves and shove this out the
speaker port (very rapid clicking). This sounds much worse and takes a
bit of complex mathematics, but you need no special hardware.
Unfortunately, I have no code for this. I've only read about it in
a README file for a program that plays Macintosh sounds through the
internal speaker port on an IBM-PC/AT.
True, the joystick is the only analog input on a classic Apple II...but for
audio digitizing it isn't too useful. You'll be limited to around 200 samples
per second from the joystick, since to read it you trigger a 555 timer circuit
and see how long it takes to time out.
Doing one-bit input from the casette port, you can get crackly-but-recognizable
speech.
If you're serious about sound on an Apple II, check out the Apple IIgs--you
can do 8-bit sound I/O through the built-in Ensoniq chip.
(Follow-ups to comp.sys.apple2.)
--
David A. Lyons, Apple Computer, Inc. | DAL Systems
Apple II System Software Engineer | P.O. Box 875
America Online: Dave Lyons | Cupertino, CA 95015-0875
GEnie:DAVE.LYONS CompuServe:72177,3233 Internet:dly...@apple.com
My opinions are my own, not Apple's.