10

There's this old piece of software still present in today's Windows called SAM that enabled C64 to speak. I remember that we could choose either screen on and worse speech quality or screen off and better quality.

Why did it work that way? Did SAM use "varying SID volume = 4 bit digital audio" trick, thus blanking the screen allowed better sample rate for phonemes?

  • 1
    As in other similar questions, this is almost certainly down to interrupt conflicts. Blank the screen, no screen interrupts, more time for audio output interrupts. – Chenmunka Oct 31 '17 at 8:46
  • 3
    Whatever Windows does that the C64 also did, it is not because it shares any software whatsoever. Software voice synthesis was produced by a bunch of companies (on the C64 see also e.g. Superior Software's Speech!) because it's a fairly simple idea. The modern stuff is unrelated to the old other than in concept. – Tommy Oct 31 '17 at 10:45
  • 1
    Just to be clear, SAM ( Software Automatic Mouth ) was not a C64 support program running on an msWindows machine. It was a speech-with-visual-mouth program available on several machines, developed in the early 1980's. I initially interpreted your question the first way. – RichF Oct 31 '17 at 11:58
  • 3
    @Tommy: True. While working at Apple, I purchased a SAM for my Apple II, and demonstrated it to the Mac team, as well as taking it with me to Hi-Toro/Amiga. Both those teams subsequently contracted with the SAM developers to do a 68000 port. – hotpaw2 Oct 31 '17 at 15:54
  • 1
    @user100858: Isn't that just ARPABET? – Ilmari Karonen Nov 23 '17 at 1:25
21

How SAM works

SAM was written to be usable on many different computers. So instead of using the SID chip in the usual way, the CPU has to work to sample the phonemes itself. The SID could have taken a lot of that on, since it has its own oscillators, waveform generators, ASDR volume control, and all that. This would all have been very useful in speech synthesis, but it is not used because the program was written to be portable.

For most phonemes, the program does a tight loop, which gets two sine waves and one rectangular function, each at a different frequency and each scaled by an amplitude, adds these three together, and stores the result (divided by a constant) in the SID's master volume register. That's good for sounding out continuants1. For other phonemes, say the sibilants2, random data and other tables were used instead. And for plosives3, I'd wager the same thing was done, but the amplitude was simply altered with each loop iteration. This arrangement, with the looping, scaling, adding, as you can imagine, takes more than a few cycles on the lowly 6502. And it is very sensitive to timing because even a few cycles here and there will change the resulting soundwave quite drastically.

Fine, but what's it got to do with blanking the screen?

On the C64, if the screen is being displayed4, then every so often the CPU gets halted for some time, to allow the video chip to read the memory faster. Between 40 and 62 cycles (depending on various details) are taken from the CPU in this way every 8 scanlines (again, depending on various details). These scanlines are called badlines, and under normal operation there are either 24 or 25 of them per frame. That means the CPU loses 960-1550 cycles every frame.

The CPU on a European C64 ran at 985 KHz, and so 1000 machine cycles is 1.015 milliseconds. That's about the amount of time, per frame, during which the CPU may not run if it is stopped by the graphics chip, which means those loops I talked about do not run during that time.

When it comes to normal human speech, a phoneme lasts only a very short amount of time. A phoneme can easily last less than, say, fifty milliseconds. Losing even 40 machine cycles puts a considerable dent in that timeslice, so they made sure that wouldn't happen, by making sure no badlines would happen, by making sure no text or graphics would get displayed.


1: continuants are vowels and consonants which can be elongated, like m, i, s,

2: sibilants (a subclass of continuants) are consonants like s, z, f, th etc. which work by constricting airflow so that it kind of hisses in the mouth.

3: stops (aka plosives), are consonants that involve blocking and then releasing airflow, like p, k, g. These sound very different from start to the finish, and cannot be pronounced for a long time

4: The VIC-II has a bit in register $d011, which blanks the display. It disables all badlines too.

  • you're probably correct though (and hence got my vote). The Atari version of SAM also blanked the display, it seems. Almost certainly it's because there's a tight CPU loop repeatedly setting a volume level in order to effect PCM audio, and therefore any CPU timing irregularities would cause audio output slurring. – Tommy Oct 31 '17 at 13:57
  • I wonder if the C64 version could be adapted to play cleanly, at least when certain sprites are disabled, without sounding bad? If one normalized the sample rate to 126 or 130 cycles and set up a CIA interrupt that would fire just after the end of a badline, that should give a stable timebase for audio output. The interrupt would take 36 cycles per sample to play from a rolling 256-byte buffer, but buffering would allow samples to be generated in groups of five at a cost of ~300 cycles/group. – supercat Mar 12 at 17:34
  • @supercat Interesting idea. I don't see any strong evidence why your idea wouldn't work. But if you wanted to go to a great effort to adapt SAM to the C64, it would probably be better to actually use the sound chip, like modern day demos seem to do. I wonder if anyone back in the day had the chutzpah to do that. It would take much less CPU time and memory, leaving these free for useful work. – Wilson Mar 12 at 20:56
  • 1
    @Wilson: Looking at the snippet of C64 code shown, there are a lot of load-modify-store sequences for each sample. If running code in zero page, the LMS sequences for five samples could be replaced by lda phase1a / adc freq1 / sta phase1b / adc freq1 / sta phase1c", etc. with the phase` values being the LSBs of addresses stored within instructions that use wavetables: ldy wavetable1 / lda (mulTable1),y / lda wavetable2 / adc (mulTable2),y / ldy waveTable3 / adc (mulTable3),y. Cute, eh? – supercat Mar 12 at 21:01
  • @supercat "running code in zeropage"? – Wilson Mar 13 at 8:52
11

SAM ran on several systems, including the C64, the Atari 400/800, and, via a 6-bit DAC board that went in one of the peripheral slots, the Apple II. The voice synthesis algorithms were later ported to 68000 for the Mac and the Amiga.

Timing jitter of the sample clock of an audio DAC causes distortion (unwanted severe phase and/or frequency modulation). On 6502 systems, the sample timing for the SAM audio output to DAC was done in software by using code paths and loops with known CPU cycle timings. So anything that could vary the timing of the software timing loops could distort the synthesized voice. Leaving the display enabled can cause a number of things (interrupts, screen refresh memory fetches, etc.) that could vary the the number of clock cycles taken by software timing loops and paths. Thus, blanking the display reduced potential distortion of the audio output due to DAC sample timing jitter.

Video blanking was not needed for synthesized audio on the Mac and Amiga because audio DAC timing was done in hardware rather than by software timing loops.

1

As mentioned above, timing distortion, especially if your CPU is heavily involved in live video generation as it is in "home computer" style machines, is an issue.

Also, such designs did not tend to be very well screened internally, and power supply wiring (especially ground layout and filtering!) was not exactly optimized for a high-grade "mixed signal" type system. Fast rise pulses (the currency of digital electronics) and low level analog signals (the currency of audio) do not readily live in peace together: Digital circuitry does not mind if eg a ground is lifted by 100mV for a microsecond, and can easily CAUSE such interference. If the same ground is used for anything analog, this could cause an analog value at audio level to be misinterpreted by several percent of full scale... Such problems have not even been fully eradicated from budget-grade, on board, sound cards in modern PCs: Audible interference from CPU activity is still commonly observed.

  • 1
    The problem on the 64 wasn't caused by the lack of video shielding, but rather the fact that when video is enabled the Commodore 64 disables the processor 25 times per frame, for 43 cycles each. – supercat Nov 2 '17 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.