[Coco] 1bit hsync nasties....

Thu Jan 23 12:16:02 EST 2014

Simon, seems like you could save an additional 4 cycles by changing ldb
#$00 to clrb in two places, no?  (ldb #$00, decb could also be replaced
with ldb #$ff, though that wouldn't save any further cycles compared to
clrb, decb.)

Art

On Thu, Jan 23, 2014 at 10:30 AM, Simon Jonassen <simon at roust-it.dk> 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 :-)
>
>
>
>
>
>
>
>
>
>
> -----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
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>