Re: Recode to Play MP3?

["Michael J. Mahon" <mjmahon@aol.com>]

mdj wrote:
> On May 25, 5:51 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > mdj wrote:
> >
> > > On May 24, 10:25 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> >
> > > > > The Transwarp only writes through when it has to (to the above
> > > > > mentioned areas)
> >
> > > > That's interesting...  So most of the RAM is "stale" when running
> > > > a TransWarp?  I wonder how much speed improvement this buys them?
> >
> > > It's difficult to say. The Transwarp certainly performs better at a
> > > given speed than the Zip, but this is primarily due to never having to
> > > invalidate cache for Main/Aux/ROM.
> >
> > The Zip has 8KB of direct-mapped cache, with 8-bit tags, so there are
> > 13 real address bits for the cache, and 3 bits (per 64KB) in the tag,
> > leaving 5 additional tag bits, to support up to 32x64KB or 2MB of
> > RAM.  It tracks RAMworks-style AUX bank switching.
> >
> > Since it's write-through, there's never a "dirty" cache byte, and
> > the cache is only used to accelerate reads (which are the vast majority
> > of accesses).
> >
> > Cache is never invalidated, but when executing "synchronous sequences"
> > a cache miss is forced for both reads and writes.
> >
> >
> > > Certainly in any application where there's a lot of moving about of
> > > data, like say a large AppleWorks word processor document, the
> > > Transwarp feels a little snappier then a 4Mhz Zip.
> >
> > Some timing tests may be in order...
> >
> > There's no doubt that the Zip wins big on the "bang per milliwatt"
> > scale.  ;-)
>
>
> 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.

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.

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.

> Code is attached. Not particularly efficient and uses 65C02 opcodes
> (PHX/PLX) which I was too lazy to remove, but since the accelerators
> it's intended to test are 'C02 equipped I didn't see that as a
> problem.
>
> Matt
>
> ----BEGIN CODE----
>                 1             XC
>                 2    DEST     EQU   $06
>                 3    COUNT    EQU   $08
>                 4    BUP      EQU   $09
>                 5             ORG   $300
> 0300: A5 08     6    INIT     LDA   COUNT
> 0302: 85 09     7             STA   BUP
> 0304: A2 00     8    COPY     LDX   #00
> 0306: DA        9    OLOOP    PHX
> 0307: A0 00     10   TFER     LDY   #$00
> 0309: A2 00     11            LDX   #$00
> 030B: B5 00     12   CLOOP    LDA   $00,X
> 030D: 91 06     13            STA   (DEST),Y
> 030F: E8        14            INX
> 0310: C8        15            INY
> 0311: D0 F8     16            BNE   CLOOP
> 0313: A0 00     17            LDY   #$00
> 0315: A2 00     18            LDX   #$00
> 0317: B1 06     19   RLOOP    LDA   (DEST),Y
> 0319: 95 00     20            STA   $00,X
> 031B: E8        21            INX
> 031C: C8        22            INY
> 031D: D0 F8     23            BNE   RLOOP
> 031F: FA        24            PLX
> 0320: E8        25            INX
> 0321: D0 E3     26            BNE   OLOOP
> 0323: C6 08     27            DEC   COUNT
> 0325: D0 DD     28            BNE   COPY
> 0327: A5 09     29   FINAL    LDA   BUP
> 0329: 85 08     30            STA   COUNT
> 032B: 60        31            RTS
> ----END CODE----

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