[Coco] 1bit hsync nasties....

Thu Jan 23 10:30:40 EST 2014

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 :-)

-----Oprindelig meddelelse-----
Fra: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] På
vegne af Steve
Sendt: 23. januar 2014 01:34
Til: CoCoList for Color Computer Enthusiasts
Emne: Re: [Coco] 1bit hsync nasties....

By using the H-sync interrupt you did let the CPU do some work while the
sound is playing. But not much work.

So, let’s to the math...

The reason why the h-sync Interrupt was used so little back in the day was
the CPU overhead. I the case of V-sync that only happens only once every
14,917 CPU clock cycles and does not take a large percentage in the way over
overhead to handle it.

Now, the H-sync happens every 57 clock cycles. The CPU uses 15 cycles to
save its registers another 15 cycles to reloaded them and finally, 9 cycles
to jump to the code and clear the interrupt flag. So far, we've used 39 of
the 57 clocks cycles (68%) just for the interrupt and we have not done any
work.

Add in the code for the to do the sounds and you are looking at another
12 (or more) clock cycles to this work for a total on 51 out of 57 or 89.5%.
As for doing a game, you only have 10.5% of the CPU to do any game work!

And that's why the H-sync interrupt was used so little back in the CoCo
1/2 days. The CoCo 3 fix a bit of the overhead problem letting you assign
the H-sync to the FIRQ and just the Interrupt overhead from 39 clock to 21.

If you are going to make a modification for the CoCo to switch the H-sync
over to the FIRQ, why not do a better by putting a programable timer on the
Cart Line? But why stop there? Why not add a sound chip or even a MP-3
player? Oh that’s right, this was to be software only solution and without
any hardware modifications. So, drop the idea of using the FIRQ on the CoCo
1/2.

The other problem with using a H-sync is the low resolution (of timing) to
getting the notes on key. As you demo showed the tones limited to the lower
octaves because anything higher will be way off key. (I don’t think I head
anything over Middle C of 261.626 Hz or even octave lower.)

If you tried the math trick (use a sum in place of a counter) that I talked
about in a earlier message, you could get the notes a bit more in key and up
an octave in range.

I could see your code working in a video game if it only used 25% of the
CPU. But using 90% for the CPU and giving game play only 10% is wasting too
much CPU time for what you get.

I'm not trying to put down what you have done. I'm just shining a bit of
light on it by the way of numbers.

Steve

On 1/22/2014 1:52 PM, Simon Jonassen wrote:
> Well John...
>
> We have a nice litte vector (secondary) at $10c
>
> Which usually holds a jmp $xxxx (somewhere in basic on a cold boot)....
>
> If we hook the hsync (which is 15750 Hz (15625 for pal)) then that jmp 
> $xxxx gets executed very fast
>
> So that jmp (4 cycles) gets executed 312 / 262 lines (per frame)
>
> 312 * 4cycles = 1248 cycles (you do the math for NTSC)
>
> What "IF" we "dared" to totally trash the $100 page by directly 
> inserting the irq code at $10c with no regard to consequence ??? Well 
> on a coco III it would fook up the firq vector at $10f... (coco II 
> uses this for cart/rs232)
>
> "IF" we dared to overwrite this, we would be saving 1200+ cycles.....
>
> If we then directed the DP to $1 (as in $10c) we could also save
cycles....
>
> If the DP irq now involved "self modifing" code we would be up on speed..
> right ????
>   
>
> Like i said... Alot of nasties going on here.....
>
> /Simon :-)
>
>

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
-----
Ingen virus fundet i denne meddelelse.
Kontrolleret af AVG - www.avg.com
Version: 2012.0.2247 / Virusdatabase: 3681/6524 - Udgivelsesdato: 22-01-2014