[Coco] 1bit hsync nasties....

Steve 6809er at srbsoftware.com
Wed Jan 22 19:34:01 EST 2014


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




More information about the Coco mailing list