Re: Recode to Play MP3?

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

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

> Even better would be writing data blocks "interleaved" on the CF card,
> and reading them back while "deinterleaving" to two successive pages.
>
> This would require two indirect addresses (if executed from ROM), but
> would delete one INY from the loop and move 512 bytes per complete loop
> execution.  The net improvement is the same as moving the non-unrolled
> 2-byte loop to RAM.
>
> Of course, storing the data interleaved would complicate life slightly
> for CiderPress...  ;-)  All utilties that access the card using CFFA
> firmware would be fine.

Snap! :-) The UNIX brigade would need to do some simple remapping
instead of just doing dd's, but that's simple enough.

Of course, all this assumes that the CFFA triggers placing the next
word in the registers by reading the registers, and not by the polling
of the status register, but that seems an easy enough logic change to
make, if indeed it's actually necessary.

A little more slack time could be created by having a pair of
registers. Reading the low byte triggers the CFFA to fetch the next
word into the alternate pair, reading the high byte swaps the pairs,
ping pong style.

> If you *really* want to run it from RAM, then you'd have to move the
> loop body to the stack (assuming that the stack has enough free space,
> and that you do enough logic to ensure that the free space doesn't
> "wrap" page 1).  Alternatively, stack "alignment" could be ignored
> by running the code elsewhere (like page 0), with space saved to and
> restored from the stack.
>
> This would be a net loss for single block reads, but for larger ranges
> would be a win.

Yeah, you're only trading 6 cycle writes for 5 cycle writes anyway.

> > Unrolling it completely would give you 10 cycles/byte or 100KB/s/MHz.
>
> And clearly too big and past the point of diminishing returns--best not
> to get greedy.  ;-)
>
> > All of the above without an accelerator.
>
> If you want the benefits of an accelerator, the move loop (for both
> reading and writing) should be put into the Csxx space of the CFFA,
> and some of the less important initialization code moved up to the
> $C800..$CFFE space.

I'd say this was never done because you have to assume the expansion
space contains ROM in order to cache it. There must be at least one
case where a card used it for something else, like scratch RAM.

> In looking briefly at the CFFA firmware, it's clear that this was
> not a consideration in laying out the code.
>
> > 2 of the (about) 11 cycles per byte must be slow, non-accelerated 1000
> > nS memory cycles. A 4x accelerator could very likely manage to execute
> > the remaining 9 cycles in 3 1000ns cycles. That would translate to a
> > rate of 5 cycles/byte or 200KB/s. Or more than a floppy a second !
> > And although I'm not 100% sure I don't think that reading so fast
> > would be a problem for the flash card.
>
> A "1x" card is 150kB/sec, and most cards are now substantially faster
> than that, so I doubt the card would be a limiting factor.

You'd probably have to drop support for "1x" cards on accelerated
machines. I would imagine you'd easily break 150kb/sec even with the
slower accelerators. A IIgs which can run anything up to 16Mhz could
potentially push the data rate in excess of 400kb/sec, and an 8Mhz ZIP
is going to break the 200kb/sec barrier.

With all these changes in place, the CFFA would become one of the
fastest storage solutions, bested (probably) by the TurboIDE card, and
the RAMFast, but this would only be noticeable on multiblock
transfers, which only happen under GS/OS.

Matt