Re: Z80 CPU Speeds? - Upgrading

[mjmahon@aol.com (Michael J. Mahon)]

Paul Schlyter wrote:

>In article <3D9BA11A.8040502@adelphia.net>,
>Steven N. Hirsch <shirsch@adelphia.net> wrote:
> 
>> One of the reasons that the Applicards were so fast was that
>> they made efficient use of the 6502 for I/O.  Unlike the original
>> Microsoft Softcard, both CPUs are running at the same time
>> (the Softcard is an either/or proposition.)
> 
>Even though, on the AppliCard, both CPU's ran concurrently, they
>rarely did something useful concurrently: when the Z80 executed CP/M
>programs, the 6502 waited for commands from the Z80.  And when the
>6502 executed commands form the Z80, the Z80 waited for the 6502 to
>complete these commands.  In addition, after the 6502 had done e.g.
>a read on some I/O device, the data resided on the 6502 RAM, which
>was inaccessible to the AppliCard's Z80.  So before the Z80 could use
>it, the data had first to be transferred, byte by byte, from the
>6502's RAM to the Z80's RAM - this was accomplished through a few Z80
>ports (which were accessible as memory mapped I/O ports to the 6502)
>combined with an internal protocol between the 6502 and the Z80.
> 
>No, the reason the AppliCard was so fast was that the AppliCard's Z80
>had its own RAM: this RAM was independent of the main RAM, and there
>was no video circuits accessing it either.  So the Z80 could run, and
>use this RAM, at full speed (4 or 6 MHz, depending on whether you
>used the Z80A or Z80B).  And the Appli-Card was significantly faster
>only on CPU-bound programs (where it ran 2 or 3 times faster than the
>SoftCard).  But on I/O bound programs, the Appli-Card was probably a
>little slower than the SoftCard, simply because of the extra overhead
>'due to the need to transfer data between the Z80's RAM and the
>6502's RAM.

I sounds like there would be a real opportunity to make the 6502
responsible for managing a disk cache in Apple memory concurrently
with AppliCard operation.  There would still be a processor-to-processor
copy, but latency could be eliminated in many cases (particularly for
sequential file accesses).  It would work even better if the 6502 cache
manager were given some knowledge of the CP/M file system, so
that non-contiguous files could be "followed" autonomously.

A suitable least-recently-used replacement algorithm would take
care of frequently accessed structures, like the directory.

Some care would be needed to handle flushing on disk swaps.

-michael

Check out 8-bit Apple sound that will amaze you on my
Home page:  http://members.aol.com/MJMahon/