> now 030 machines will vm_fault() if RETINE_SPEED_HACK **is not** defined,
> and 040 machines will vm_fault() if RETINA_SPEED_HACK **is** defined. 

I'd like to clarify the situation as far as I remember the details. Sitation
is like this:
- with RETINA_SPEED_HACK enabled, the driver uses some addressing mode tricks
  of the NCR chip to move data. It has turned out that this kind of addressing
  somehow does not seem to work with the '40. So, on the '40, the driver is
  just not scrolling text, or not scrolling all the text (somebody with an
  '40 will have to report here).
- without RETINA_SPEED_HACK defined, the driver uses bcopy/bzero calls to
  do the scrolling. Now.. these calls were in there for ages, without ever
  being used but in the VERY early stages of the driver. With them enabled,
  the system crashes with a vm_fault as soon as the screen is supposed to be
  scrolled up (e.g. do an ls -l and as soon as the lines hit the bottom of the
  console screen, and the driver is supposed to scroll, boom). My simple
  guess is that:
  a) this happens on both '40 and '30, OR the access thru illegal addresses
     causes different results on the '30 and the '40, or with the '40, out of
     coincidence, the addresses just happen to be valid. Something like that.
  b) it's a simple bug, probably one of those bcopy/bzero calls tempering with
     illegal addresses
  It's very probable it's some bug like this, because, as I said, the code 
  hadn't been used for ages...

Sorry, I'm not available for testing this out (two more weeks of
military service coming up right now...), but I hope this information
will make your job easier to find the bug.

-Markus
-- 
EUnet AG                                        Markus Wild
Zweierstrasse 35    Tel:     +41 1 291 45 80	mw@eunet.ch
CH-8004 Zuerich	    Fax:     +41 1 291 46 42    S=mw;P=EUnet;A=EUnet;C=CH
> The most exciting phrase to hear in science, the one that heralds new
> discoveries, is not "Eureka!", but "That's funny ..."    -- Isaac Asimov