Michael J. Mahon wrote:
Michael J. Mahon wrote:mdj wrote:On May 20, 5:31 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:Michael Kent wrote:Michael J. Mahon <mjma...@aol.com> wrote:Michael Kent wrote:schmidtd <schmi...@my-deja.com> wrote:I wonder if Dave Schmenk's 30% faster CFFA firmware would help?It doesn't look like it. His firmware doesn't seem to affect GS/OS access, and both Oversampler and LongPlay are GS/OS programs.Have you installed Dave Lyons' GS/OS CFFA driver?Yes.I wonder if the read (and/or write) speed of the CFFA is influenced by the speed of the CF card? Theoretically, a "1x" card would support 150KB/sec, so unless there is something peculiar going on, *any* CF card should be about as fast as an Apple could transfer data--and much faster than the 11kB/sec that sampled sound would require.It seems the CF cards have unusually long setup times for data transfer that considering the typically small IO transactions that Apple II's do, severely impacts the total I/O throughput you can achieve - apparently to the degree that even 1980's class hard disk drives can outperform it. The hardware design of the CFFA would need to incorporate some sort of asynchronous buffering that enabled the CF card to be read and filling a buffer while the card firmware emptied it. I've not looked at the CFFA's design in detail, but I'm fairly certain it doesn't utilise a technique like this, and as a result manages only modest data transfer rates.You are correct, the CFFA does not buffer data, let alone prefetch. Since a straightforward "ping pong" buffer allocation in the 64KB sound RAM would allow 32KB transfers from the CF card, it should be possible to prorate startup time pretty easily in the application, assuming that the CFFA doesn't start over from scratch with each block.In the measurements I made while characterizing the performance of the NadaNet File Server, I observed a 32KB/sec bandwidth reading 32KB of data from a CFFA using the ProDOS BLOAD operation on an 8MHz Zipped //e. This is a "worst case" number, since each BLOAD re-OPENs the file before reading, for a .28 second overhead in my directory system. The bandwidth for incremental transfers (without OPEN overhead) is 44.4KB/sec. As I recall, the transfer bandwidth was not a function of accelerator speed, so the card sets this bandwidth. Since continuous 11kHz sampled sound would only require a fraction of this bandwidth, I'd say that the CFFA is not the speed limitation.
After thinking about it, I realized that the file server test may have introduced some additional overhead, so I repeated a very simple FOR loop BLOAD test, reading the first 32KB of a large binary file. At 1MHz, the time to BLOAD 32KB was 0.92 seconds, for a net bandwidth of almost 35KB/sec. At 8MHz, this bandwidth rose to 41KB/sec, so processor speed is not a major factor. This speed is plenty to support continuous playback. -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."