Re: Z80 CPU Speeds? - Upgrading

[pausch@saaf.se (Paul Schlyter)]

In article <20021003153110.01209.00012216@mb-mq.aol.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:
 
> 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.
 
The latter is "overkill" I think, but a disk cache keeping 5 or so
tracks in 6502 RAM would be quite feasible.  One could also borrow
the disk read code from the Apple Pascal system, because that code
has one great advantage: it can read one track at one revolution of
the disk, de-nibblizing the sector contents on-the-fly!  (as opposed
to the RWTS of Apple DOS, CP/M and ProDOS, which requires at least
two revolutions of the disk to read one track; the sector interleave
of Apple CP/M disks will require three revolutions to read all sector
if they're read in ascending logical sector number).  Buffering a few
tracks t can thus be done quite rapidly.
 
> A suitable least-recently-used replacement algorithm would take
> care of frequently accessed structures, like the directory.
 
The directory easily fits on one track.
 
 
> Some care would be needed to handle flushing on disk swaps.
 
Here CP/M itself comes to help: if you're writing to a CP/M disk,
you're not supposed to swap it until you've warn booted CP/M.
So the "Reset Disk System" BDOS function is a natural place to
implement writing a dirty cache to the disk.
 
 
But who would do this?  Relatively few Apple users use CP/M, and
only a minority of the Apple CP/M users use the Appli-Card.  Also,
doing this successfully requires skills, and people who have these
skills are likely to find more interesting projects elsewhere.
 
Basically this should have been done some 20 years ago -- today I
think it's too late.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se
WWW:     http://hem.passagen.se/pausch/index.html
         http://home.tiscali.se/~pausch/