🚀 go-pugleaf

Blair Leduc (b.leduc@ieee.org) quotes Joel and replies:

 > > As for the mouse dying under K-Windows (and lost characters during disk
 > > access while downloading), the fix is to do:
 > >
 > >  dmode /h0 maxcount=2048
 > >  dmode /dd maxcount=2048
 > >
 > > You can put that in your startup file, or you can do it once, 'save'
 > out > the modified 'h0' and 'dd' descriptors and make a new boot file.  I
 > > believe it was Ken Scales that discovered this.
 >
 > Unfortunately, performance drops into the basement (as far drt500
 > is concerned).  With maxcount=65535, drt500 reports a transfer rate of
 > approx. 1.7 MB/s, with maxcount=2048, drt500 reports 0.3 MB/s (found with
 > drt500 /dd@ 128).

Actually, I generally suggest modifying /dd to maxcount=2048, and keeping /h0
at 65535.  This allows using the higher maxcount for occasions when you
really want every bit of speed, as when running flickers.

Yes, there is a sacrifice in speed, but drt500 doesn't come close to
giving a meaningful reflection of the actual significance.

Some more meaningful speed comparisons might be:
                                                  2048        65535
  time fgrep zebr /dd/sys/.ispell/words           6 sec       5 sec
     (words is the ispell ascii dictionary
     with 476900 bytes)

  run ispell on a file; first error display       6.3 sec     5.8 sec
     (this includes loading the 578352 byte
     ispell.hash file)

  flicker iclrun.fli (1346134 char; til display)  5.2 sec     2.2 sec

The last two were timed by hand, so contain "human response time" errors.

Fact of the matter is, though, that a maxcount of 65535 is just plain and
simple, bad "engineering practice" for multitasking with the MM/1 system
architecture.  The DMA implementation just doesn't lend itself to that
setup.  With a fast hard drive (e.g., Quantum), and maxcount=65535, if
you truly have a transfer rate of 1.7 MB/s, you are effectively telling
the hard drive "you can dominate the bus for the next 65535/1700000 second."
This would be somewhat analogous to masking interrupts on the CoCo for
about 0.038 second.

The mouse lockups, BTW, are due to incorrect error recovery (overrun
error) in the mouse driver.  I believe that Kevin D and Carl K have
since discovered an error in the Motorola documentation for the serial
chips.

 --------------------------------------------------------------------------
 Ken Scales   Delphi:KSCALES   Internet:kscales@delphi.com   CIS:74646,2237
     I've ordered G-Windows for my MM/1:  Have you?  Deadline Dec 31/93.