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

Re: Recode to Play MP3?

mdj wrote:

On May 23, 5:23 am, "Michael J. Mahon" <mjma...@aol.com> wrote:



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.


Well the Transwarp doesn't have cache thrashing issues for either Main
or Auxiliary RAM, or ROM, since it replaces the whole lot with its own
fast RAM. Caching comes into play for Ramworks cards and some sorts of
normal slot memory cards.


Actually, it cannot safely cache "sub-bank-switched" regions of memory
without "knowing" their bank-switch protocols, and, unfortunately, the
$C800-$CFFE region is such a sub-bank-switched region.  If it could be
made slot-specific, and the cache logic took the slot that originated
the /IOSTROBE into account, it could work, by disabling caching of the
extension space when switched in by certain slots.  I don't know of any
accelerators that go to this length.


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.



Pretty much.


This is the area that needs investigation.


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



Yes. bandwidth to sound RAM might be impeded while the DOC is running,
necessitating faster Disk IO.


The DOC bandwidth shouldn't have to be very high, but who knows?
Certainly, the DOC has priority for access to the sound RAM.


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.



Depending on the number of gates in the CPLD, and how much speed
differential there is between the card and the PIO loop, a small
register file might do the trick. I think though the PLD on the CFFA
is only 1200 or so gates, so unless the number of needed registers is
really small, it ain't gonna fit. So yes, it's possible that external
RAM is the only way to do it.



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



And Jorge has already started... :-)


Right!  We're on the same page, so to speak...  ;-)

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