Re: Recode to Play MP3?

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

On May 23, 7:21 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

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

A lot of extra logic for a very small gain, I'd venture.

> >>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 guess superficially speaking it *is* a 32 voice chip, and it seems
reasonable that whatever bandwidth it uses while active is constant,
regardless of the number of voices. I wish I had a IIgs hardware
reference handy.

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

:-) a phenomena that seems to be almost universally true, although
most of the time we tend to walk through the page from either end,
meeting somewhere between $7F and $80. It's a lot of fun discovering
that, though :-)

Matt