Re: Recode to Play MP3?

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

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

> > That's certainly true :-) Ok, so I devised a small 'memory bandwidth'
> > test which simply copies then restores the zero page to an arbitrary
> > memory page 256 times, multiplied by the value in memory location $08.
> > The destination page is set in locations $06-$07.
>
> > With the iteration counter in $08 set at $10, it's moving a megabyte
> > of data to the specified location and back again.
>
> So:  2*256*256 = 128KB of data,
>          128*16 = 2MB total moved.
>
> > Unaccelerated Apple II: 34 sec
> > Transwarp Apple II to location $6000: 10.1sec
> > Transwarp Apple II to location $2000: 11.2sec
>
> > So the Transwarp shows a 9.8% improvement in this test when not
> > writing to a 'write-through' memory location.
>
> > It would be interesting to see how the Zip Chip fares in this test at
> > both 8Mhz and 4Mhz, and if its programmable speed can get it
> > reasonably close to 3.6Mhz (which the Transwarp runs at) it would be
> > quite interesting to see this too.
>
> I verified your 34 sec unaccelerated number, and tried the
> Zip Chip at 8MHz.  Its time is 4.3sec, independent of address.

Well now, that's a lot faster than I was expecting - I was
anticipating somewhere around 7sec ...

> I tried to get a 4MHz number, but couldn't get ZIP.SYSTEM to
> set the speed for some reason (I've never used it at other than
> 8MHz and disabled).
>
> As for getting closer to 3.58MHz, the closest multiple offered
> (that I couldn't get it set to ;-) was 3.333MHz, so that comparison
> won't be very enlightening.
>
> It would be good to get a point at 4MHz to see where the intercept is,
> but, as I said, I can't seem to get it set to any speed but "full on".
>
> A straight linear extrapolation to 3.58MHz would be 9.6sec.

Well this test was 'designed' to focus on writeback speed, and it
would seem that the loops have to be a lot tighter to cause the Zip to
stall at 8Mhz, so I concur you're correct that a linear extrapolation
is quite accurate. Of course, it may be different if there's cache-
line contention going on, like in a large block copy, but I
deliberately left that out to focus on writes. An alternative test
might do the same thing by moving 16kb of data back and forwards from
AUX to MAIN memory using AUXMOVE (which is quite slow too since it
uses the stack to 'bounce' the data between banks)

> But, of the 4.3sec time at 8MHz, 2.06sec is spent doing 2MB of stores
> at 1MHz, which is independent of Zip clock speed (since it's always
> write-through).  That leaves 2.24sec of accelerated time at 8MHz.
>
> If this accelerated part were run at 1MHz, it would take 8 times longer,
> or 17.92sec, which when added to 2.06sec gives a total of only 19.98sec.
> Therefore, the 2MB of writes, even though they take a full cycle to
> process, are not interfering substantially with the high speed execution
> of the Zip Chip.  It undoubtably has a 1-byte "write buffer" that allows
> it to keep running unless another byte is written before the buffer is
> emptied into Apple RAM.
>
> Since only half the store bandwidth is used by these loops, it never
> stalls for writes, and the linear extrapolation is closer to the truth.

Agreed. Well this is interesting, as it shows that the write-through
mechanism of the Zip is not only asynchronous, but buffered too,
perhaps only by 1 byte, but still works quite well.

The numbers from the Transwarp indicate that its synchronous design
running to 3.6Mhz RAM doesn't scale as well as the Zips cache design
does, which I didn't expect. If the linear extrapolation you mentioned
holds true at 3.6Mhz, it would seem the Transwarp is actually slightly
underperforming, either due to DRAM refresh getting in the way, or
DRAM speed limitations. Or it could simply be that the Zips 'lazy'
write mechanism from cache->memory is a big performance win.

Most interesting of all, it indicates that 8Mhz is not the ceiling
speed for the Zip acceleration architecture either. It would appear
even 16Mhz would work quite nicely under this test.

Of course as mentioned, the Zip never has to reload a cache line under
this test, so perhaps bus contention of loading the cache *and*
writing would expose a limitation, but that requires a different
test...

Matt