[Coco] 1bit hsync nasties....

[Steve]

Simon,

I was going over your numbers and found a few items.

First, your frequency table is off by one octave. B in octave 5 is 
987.767 Hz, not the 493.883 Hz you stated in your last message. So, the 
note range is C in octave 0 to b in octave 4.

The higher notes are bit out of key by 0.4% to 1.2%. This is from a 
rounding off error. Since you can’t loop 16.893 cycles, you round up to 
17. With this timing is used for 1/2 waveform, the error rate is 
doubled. Using a 16-bit summation system in place of a simple counter 
would get the error rate so low that it would be in perfect key. But the 
extra clock cycles of summing a 16-bit number is not worth it.

But your code is creating a much larger 6.24% error on the higher notes. 
When the code flips the sound bits of the DAC and reloads the counter 
the code’s total time in the Interrupt jumps from 48 to 75 cycles. But 
the H-sync happens every 57 clocks. Because you clear the H-sync flag at 
the end of the H-sync code you miss a complete H-sync. (As you already 
pointed out.) This can be fix by subtracting 1 from every entry in the 
note frequency table.

The funny thing is that when you lose a h-sync because the the code 
takes longer than the 57 clock, the time for game work jumps from 15.8% 
to 66%. But that is only once out of 16 H-Sync in the highest note and 
down to 1 out of 240 H-Sync for the lower note. This timing mistake will 
only get you a few percent more game work time since it happens so little.

Since your code varies how much CPU time it used for any given note, how 
are you keeping the frame rate at a constant level? You can’t use the 
V-Sync to control and game timing.

But you still have the fact that the 48 out of 57 cycles the code is 
running your sound code and not the game. That’s only 15.8% of the CPU 
is being used for the Video game. It maybe higher than 10% in my last 
message, but 15% is a far cry from 100%! That would be like clocking the 
CoCo at 0.141 MHz in place of 0.895 MHz.

Back in the early days of the CoCo, we all looked at what you are trying 
to pull off and we found the tradeoff was not worth what you get. It 
would just make the Video game too slow. Tandy knew this from all our 
complaining and that’s why they create Speech Sound Pak in the first place.

By the way, over driven square waves don’t sound very good on the output 
of the CoCo. Try flipping the audio DCA with some more like $80 or $90 
in place of $F0. I looked at the waveform on the samples that you given 
out there is a lot of harmonic distortion in them.

Steve

On 1/23/2014 7:30 AM, Simon Jonassen wrote:
> Hi Steve !
>
> I appreciate the advice with the math thing, by using a 16bit value you can
> achieve much better sound resolution and pitch accuracy....
>
>
> What I will do, is explain some more theory about this player, the original
> post just exposed some of the nasty tricks involved in getting it running in
> HSYNC on the coco II !
>
> If you study the code, (which has since been updated for more speed), you
> will notice a 48 byte table:
>
> fcb 	$ff,$f0,$e3,$d7,$cb,$c0,$b4,$ab,$a1,$97,$90,$88  etc etc etc
>
> That would be the frequency table for the notes.....
>
> 48 values = 48 notes ranging from c-1..b-5 (32.7Hz..493.88Hz)
>
> To hear it play all 48 notes, follow this link:
>
> http://www.roust-it.dk/coco/1bitzix/scale.wav
>
> The table was worked out using the following formula:
>
> (15750/Freq)/2
>
> 15750 being the hsync speed
> Freq being the desired output frequency (eg 440Hz for A)
> /2 being as you have to flip the bit....
>
> So it does play a "bit" more than middle-c
> ----------------------------------------------------------------------------
> -----------
>
> The cycle count for the IRQ is as follows:
>
> irq entry			;19 cycles        (ALL REGISTERS STACKED)
>
>
>
> next7		dec	<$80		;6 cycles
> 		bne	nexta		;3 cycles
> inner		ldb	#$00		;4 cycles
> 		stb	$ff20		;5 cycles
> volume	eorb	#$f0		;4 cycles  	
> 		stb	<$11		;4 cycles 	
> my2		ldb	#$00		;4 cycles  	
> 		decb			;2 cycles  	
> 		stb	<$80		;4 cycles  	
> nexta		lda	$ff00		;5 cycles
> 		rti			;15 cycles
>
> bestcase			;48 cycles		(bne taken to ACK)
> worstcase			;75 cycles		(whole routine)
>
>
> ----------------------------------------------------------------------------
> -----------
>
> So, you can see that it will actually take more than 1 scanline to complete
> !
>
> Is that a bad thing ?
>
> NO ! It just means thats it's playing on alternate scanlines (the hsync
> always runs 15Khz, if you ACK it or not, is up to you)
>
> so you actually have more cpu power left than your proposed 10%.....
>
> /Simon :-)
>