Re: Recode to Play MP3?

[mdj <mdj.mdj@gmail.com>]

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

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

Agreed. And yet it skips... GS sound guru's speak up! :-)

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

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

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

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

Matt