Re: Recode to Play MP3?

[bieling@terra.es]

On May 24, 9:38 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> biel...@terra.es wrote:
> > On May 23, 6:44 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> >>If you want the benefits of an accelerator, the move loop (for both
> >>reading and writing) should be put into the Csxx space of the CFFA,
> >>and some of the less important initialization code moved up to the
> >>$C800..$CFFE space.
>
> >>In looking briefly at the CFFA firmware, it's clear that this was
> >>not a consideration in laying out the code.
>
> > The slightly unrolled version is 30 bytes long. Non-unrolled it's just
> > 16 bytes long.
> > Somebody should have a look and see if it still fits in there.
>
> > The STA indirections should have to stay, though, adding 2 cycles
> > each.. :-(
>
> The absolute, indexed STA's take 5 cycles, not 4, so indirection only
> cost one extra cycle.

Oops.

> Absolute, indexed LDA's take 4 or 5 cycles (if page-crossing), and
> indirection is also a 1-cycle penalty there.

Hey, they don't have to be indexed : IOSelect space code for each slot
is at a different page in the CFFA ROM : the code can be slot-
specific, so that it will take just 4 cycles no matter what if the
LDAs are made absolute, and they can be made so.

> So the net penalty for execution from ROM is only 2 cycles per byte.

Yep... The figures were right after all.

> > Non-accelerated rates would be
> > ((6+4+2)*4+3)/4=12.75 cycles/byte -->> 78.43 KB/s (slightly unrolled)
> > ((6+4+2)*2+3)/2=13.50 cycles/byte -->> 74.07 KB/s (non-unrolled)
>
> > Note that because this code is called from c800.cfff ROM space, and it
> > has to return back afterwards, moving the code adds a JSR+RTS
> > overhead, or 2 JMPs.
>
> The improvement from unrolling drops rapidly as the degree rises, and
> the cost for maintaining, saving, and restoring multiple page 0 pointers
> rises.  The loop is already unrolled to two bytes per iteration, so
> a lot more unrolling would require some justification.

Multiple page 0 pointers ? I don't see what does it have to do with
unrolling ?
The justification is that *if there is room left* in IOSelect space,
better to use it to unroll than to leave it empty. Unrolling just once
gives you an additional 4.3KB/s. Succesive "unrollings" won't give
that much, but why would you prefer to leave IOSelect space unused
instead ?

> As I pointed out, writing and reading data "interleaved" eliminates
> an INY per two bytes, which is equal to the saving from moving the
> code to RAM.

At the cost of compatibility... among CFFAs !
At the cost of compatibility... with CiderPress !

> The critical issue is learning (from Rich) whether it is actually
> necessary to poll the status register on each iteration.

Yes, that's been a brave assumption.

> Ironically, this is also the big issue in moving sound data from RAM
> to sound RAM.  I checked the hardware reference, and it says that the
> sound GLU status register must be polled before any access to the data
> register.
>
> I see also that a pair of oscillators is requires to play continuously,
> ping-ponging in activity.  All other oscillators can be disabled (except
> perhaps the IIgs "clock" oscillator), which should reduce the "DOC busy"
> time to a small percentage of the time.
>
> The RAM to sound ROM move loop, with the status poll in but assumed to
> practically never loop, results in a 21 cycle/byte loop, which is plenty
> fast enough for continuous sound, leaving another 71 cycles/byte for the
> I/O operation and synchronization.
>
> Bottom line, if a continuous sound player skips, there is needlessly
> inefficient code involved--I'm guessing a tool call.

If you're talking about the ensoniq chip, of which I know nothing but
the name, you'd better ask Huibert, the author of SoundSmith, tell him
that Jorge told you to ask. I'm sure he'll be glad to answer your
questions... as long as 20 years haven't erased his memory.. :-)

--Jorge.