Re: Recode to Play MP3?

["Michael J. Mahon" <mjmahon@aol.com>]

bieling@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.

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

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

> 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.

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.

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

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.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."