Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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?
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.
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.
