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

Re: Recode to Play MP3?

mdj wrote:

On May 22, 3:35 am, "Michael J. Mahon" <mjma...@aol.com> wrote:



Out of curiosity I repeated your test on my IIe, which has no CFFA,
but instead a Rev C. SCSI card fitted.



With the Transwarp turned on (3.6Mhz), A 32KB BLOAD loop yielded 32KB/
sec. With it turned off, 26KB/sec


So at least a CFFA is faster than a Rev. C.



Acceleration also seems to make more of a difference on the Rev. C
(About 23% vs. 14%) I would guess it has something to do with slot
independant firmware forcing the use of indirect addressing in the
copy process. The CFFA IIRC duplicates the firmware for each slot,
making it simpler to write an efficient copy loop.


The copy loop is not location-dependent, so that shouldn't be a
factor.

Whether the copy loop is executed from ROM or RAM is an issue, since
ROM execution would require indirect addressing, adding two cycles to
the copy loop time, for a 68kB/sec copy rate instead of 78kB/sec.

Further, using indirection significantly dilutes the benefits of loop
unrolling, since each LDA/STA pair requires another page zero indirect
address--which must be saved, restored, and updated once per page.

Still, a net BLOAD bandwidth of 32KB/sec and a move bandwidth of
68kB/sec produces an overall read/move bandwidth of almost 22kB/sec,
which is twice what is required to sustain continuous sound.


Of course it *might* be something to do with the different caching
architectures of the two accelerators as well, as the speedup curve of
the two is different - such are the dangers of a non Apples to Apples
comparison :-)


Since the data range is constantly moving through the cache addresses,
I doubt that any persistent thrash effects would be observable.


To get some contrast, I ran the same test against a RAM disk, which
yielded 160KB/sec. This figure is probably representative of an 8-bit
Apple II's "terminal IO velocity" :-)


I presume this was with the TransWarp enabled, since just a simple
(not unrolled) 1MHz move loop has a "bandwidth" of about 78KB/sec.



Yes.



It certainly is if the sound data is raw, and requires no post-
processing, but even a modest amount is going to necessitate double-
buffering, and 30-40KB/sec is going to be insufficient. Even the
overhead of a GUI could be enough to absorb sufficient cycles to cause
under run conditions.


The sound players we are discussing all play only raw, 11kHz sampled
sound, so the only post-processing requirement, the replacement of
$00 samples with $01 so as not to stop the DOC, is trivially done
within the move loop (at an average cost of another 2 cycles, which
drops the copy bandwidth to 68KB/sec), assuming that copies from RAM
to sound RAM are the same complexity as RAM-RAM copies.

Triple-buffering is inherent, in that file data must be read into RAM,
then copied to (the inactive) half of the sound RAM before the active
half is finished playing.  When the DOC toggles to the second half,
then the application can start copying the to the first 32KB.

As a result, there is the time for the file I/O, plus the time for the
copy to sound RAM, that must be accomplished before the DOC finishes
playing half of the sound RAM (32768/11025 = 2.97 seconds).

There should be plenty of time unless the protocol for filling half
of the sound RAM is really a mess.



But it seems not to work, so the applications are likely not efficient
enough at the CFFA's IO levels. It seems a reasonable hypothesis that
both apps were written on machines with faster IO peripherals.


Then either moves to the sound RAM *are* a "mess", or the application
and/or some tool is doing it very inefficiently.


I completely agree that in theory the CFFA is plenty fast enough to do
the job.



Of course, the aforementioned applications were designed on hardware
with much better throughput than the CFFA. In the case of Oversampler,
I'd doubt that there'd be enough inefficiency in the application that
could be removed to make it work with slower IO devices.


As noted, I don't think there is a problem.  Didn't these apps work
with a Rev. C SCSI card?



(other) Michael mentioned they work OK with a high-speed SCSI card. A
high-speed SCSI or RAMFast under GS/OS is a very different beast to
either the CFFA or the Rev. C. I suppose it's possible that a
particularly sluggish CF card is the culprit, but it seems equally
likely that the apps were written with the faster DMA based
peripherals in mind, and never optimised for the slower peripherals.


Indeed--but the question still hinges on how fast data can be moved
from RAM to sound RAM.  I would actually expect a "slinky"-style of
interface to the sound RAM, considering what is stored there, but I
haven't yet taken the time to research it.  (I figured someone who
knew this area well would chime in.  ;-)


I wonder how much extra hardware would need to be added to the CFFA to
get a dramatic improvement? I would suspect that adding a 512 byte
buffer and implementing the IDE/ATA readblock/writeblock in hardware
would eliminate a lot of round-trip-sync delay, but I don't know if
the PLD on the CFFA has sufficient gates for something like this.


The problem is much more fundamental--the CFFA does not have either
RAM or a microcontroller--the 6502 does it all.



I realise that - the point I was making was the CFFA hardware design
is based around a CPLD. A state machine and sequencer to execute the
IDE read/writes in hardware into a buffer (which the firmware would
then presumably start reading from after initiating a read) seems like
a reasonable compromise that would keep the CFFA a PIO device and thus
compatible with all Apple II's, while considerably increasing
performance.


But it doesn't have any RAM, either!  You are actually proposing a
new CFFA hardware design.

Since flash memories can sustain megabyte/second transfers, there must
be something pathological going on that interferes with the ability to
transfer data at the speed of a copy loop--probably handshaking (though
I would expect that to be handled in the CPLD).  Or maybe the CF card is
natively a 16-bit interface, and the CFFA sets it up twice to read each
16-bit data item as two bytes...  Time to look at the CFFA firmware...

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