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

Re: Recode to Play MP3?

mdj wrote:

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.


Right--that could easily be made transparent to the firmware.


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.


No, all RAM/ROM space is treated as read/write--it's just that ROM
space never gets "dirty"--but all that is moot since all caching is
write-through (as it needs to be for I/O registers and video memory).

The only problem for a caching accelerator is when the contents of
a memory address--RAM or ROM--changes for some reason other than a
store instruction--like bank-switching or DMA.

(And, yes, the Vulcan controller bank-switches both ROM and RAM into
the expansion space--but here the problem is that the caching can't
interpret the bank-switching to invalidate the cache, not that there
is RAM in the space.)


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.


Not a problem--if you wanted to use a slow card, you would just mark
that slot "slow" to the accelerator.


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.


And maybe not even those, at least on a //e, since DMA is not allowed
with most accelerators--certainly not with a Zip Chip.

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