Re: Recode to Play MP3?

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

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.

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

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

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.

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

Matt