[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recode to Play MP3?

bieling@terra.es wrote:

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.


Good point, for the LDAs from the device space.  But indexed LDAs
that don't cross pages (as would be the case for addressing device
space) also take 4 cycles.  ROM is not a penalty.


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


Well, since only the STA (in the read case) is indirect, indexed, the
net "ROM penalty" per byte is only 1 cycle.

And the issue of where to put a RAM version is still outstanding...


Yep... The figures were right after all.


Nope.


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 ?


I was assuming that you'd want to eliminate the INYs as well...


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 ?


I'm trying for the least impact on the well-tested CFFA firmware.


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 !


True, you'd have to upgrade all your CFFA's in a synchronized way,
and I was thinking of a PC or Apple utility to interleave the data
on any cards...

But you're right--it's a pain.  It's a shame that this approach
wasn't taken before there were a lot of cards.  ;-(


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.


Although, given the bandwidth of the cards, it's not unreasonable.

However, Bill Garber just reminded me that the CF card may not be
*uniform* in its access time.  In particular, it may *occasionally*
"take a vacation" to adjust its internal state, and only manifest that
to the outside world as going "busy" for a while.

I'm beginning to realize that I need to know a lot more about CF cards,
as well as about the CFFA card.


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


That's a good idea--though the problem is compounded by the relatively
sparse documentation on the GLU chip, especially its timing/buffering
characteristics.

Much of what is needed could be determined by experimentation, but for
me, the IIgs is not a high priority.  ;-(

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