Subject: Bug fixes for 644



I've made myself a crude debugger from scratch, and I'm on the warpath.
Gee it feels good to be kernel hacking again :-)

All fixes are relative to .644 and there are more to come.

Bug:

When the mouse pointer appears, garbage also appears in the middle of
the screen.  The problem is that grf_cc doesn't convert KVA to PA for
sprites in all necessary places.

Fix:

*** grf_cc.c.old	Fri Oct  1 22:28:09 1993
--- grf_cc.c	Fri Oct  1 23:00:49 1993
***************
*** 210,215 ****
--- 210,216 ----
    unsigned long rowbytes = fb->fb_width >> 3; /* width of display, in bytes */
    u_short *plptr;
    u_short c, i, strt, stop;
+   u_long footp;
  
    /* get PA of display area */
    screen = (unsigned long) fb->fb - (unsigned long) CHIPMEMADDR;
***************
*** 276,284 ****
      u_short addr = CUSTOM_OFS(sprpt[0]);
      u_short i;
      for (i=0; i<8; i++) {	/* for all sprites (8 of em) do */
!       *spr++ = addr; *spr++ = HIADDR(&pointer->footer[0]);
        addr += 2;
!       *spr++ = addr; *spr++ = LOADDR(&pointer->footer[0]);
        addr += 2;
      }
    }
--- 277,291 ----
      u_short addr = CUSTOM_OFS(sprpt[0]);
      u_short i;
      for (i=0; i<8; i++) {	/* for all sprites (8 of em) do */
!     	/*
!     	 * dej 1-Oct-93: Make sure to convert KVA to PA for the unused sprites too!
!     	 *    Otherwise you get junk on your screen (well, mine at least :-)
!     	 *    I've also nuked a few "pointer from integer w/o cast" warnings.
!     	 */
!     	footp = (caddr_t)&pointer->footer[0]-CHIPMEMADDR;
!       *spr++ = addr; *spr++ = HIADDR(footp);
        addr += 2;
!       *spr++ = addr; *spr++ = LOADDR(footp);
        addr += 2;
      }
    }
***************
*** 330,344 ****
    struct ccfb *fb = &ccfb;
    SPRITEPTR *pointer = (SPRITEPTR*)fb->pointer;
    COPPERLIST *cop;
  
      /* some cleverness... footer[0] is a ZERO longword in chip */
    cop = (COPPERLIST*)fb->cop1;
!   cop->sprites[num*4+1] = HIADDR(&pointer->footer[0]);
!   cop->sprites[num*4+3] = LOADDR(&pointer->footer[0]);
  
    cop = (COPPERLIST*)fb->cop2;
!   cop->sprites[num*4+1] = HIADDR(&pointer->footer[0]);
!   cop->sprites[num*4+3] = LOADDR(&pointer->footer[0]);
  }
  
  /*
--- 337,354 ----
    struct ccfb *fb = &ccfb;
    SPRITEPTR *pointer = (SPRITEPTR*)fb->pointer;
    COPPERLIST *cop;
+   u_long footp;
  
      /* some cleverness... footer[0] is a ZERO longword in chip */
+     /* dej: more KVA->PA :-) */
    cop = (COPPERLIST*)fb->cop1;
!   footp = (caddr_t)&pointer->footer[0]-CHIPMEMADDR;
!   cop->sprites[num*4+1] = HIADDR(footp);
!   cop->sprites[num*4+3] = LOADDR(footp);
  
    cop = (COPPERLIST*)fb->cop2;
!   cop->sprites[num*4+1] = HIADDR(footp);
!   cop->sprites[num*4+3] = LOADDR(footp);
  }
  
  /*
***************
*** 660,666 ****
    gi->gd_regaddr = (caddr_t) fb; /* XXX */
    gi->gd_regsize = 0;
  
!   gi->gd_fbaddr  = fb->fb - (u_char *) CHIPMEMADDR;
  #if 0
    /* mykes kludges here to make gi look like 1 bitplane */
    gi->gd_fbsize  = fbsize/2;
--- 670,676 ----
    gi->gd_regaddr = (caddr_t) fb; /* XXX */
    gi->gd_regsize = 0;
  
!   gi->gd_fbaddr  = (caddr_t)fb->fb - (u_long)CHIPMEMADDR;
  #if 0
    /* mykes kludges here to make gi look like 1 bitplane */
    gi->gd_fbsize  = fbsize/2;

Bug:

The key sequence CTRL-6 sends 0x1E on most Unix machines, but not here.
This is noticed since CTRL-^ is the "swap file" command in vi, which
I use a lot.

Fix:

*** ite.c.old	Fri Oct  1 23:09:00 1993
--- ite.c	Fri Oct  1 23:09:03 1993
***************
*** 750,756 ****
    if (! (key.mode & KBD_MODE_STRING))
      {
        if (mod & KBD_MOD_CTRL)
! 		  code &= 0x1f;
  
        if (mod & KBD_MOD_META)
          code |= 0x80;
--- 750,760 ----
    if (! (key.mode & KBD_MODE_STRING))
      {
        if (mod & KBD_MOD_CTRL)
!         /* dej 1-Oct-93: Map CTRL-6 to CTRL-^ for vi.  Should we have a CTRL keymap? */
!         if (code == '6')
!           code = 0x1E;
!         else
! 			 code &= 0x1f;
  
        if (mod & KBD_MOD_META)
          code |= 0x80;

Bug:

The vn.c code assumes the existence of the NFS filesystem in the kernel.
This is wasteful on a non-networked machine.

Fix:

*** vn.c.old	Mon Sep 27 11:55:37 1993
--- vn.c	Mon Sep 27 12:15:15 1993
***************
*** 427,441 ****
  	register struct vn_softc *vn;
  	struct vnode *vp;
  {
! 	extern struct vnodeops ufs_vnodeops, nfsv2_vnodeops;
  
  	if (vp->v_op == &nfsv2_vnodeops)
  		vn->sc_maxactive = 2;
  	else
  		vn->sc_maxactive = 8;
  
  	if (vn->sc_maxactive < 1)
  		vn->sc_maxactive = 1;
  }
  
  vnshutdown()
--- 427,449 ----
  	register struct vn_softc *vn;
  	struct vnode *vp;
  {
! 	extern struct vnodeops ufs_vnodeops;
! /* dej 27-sep-93: This code assumes you have the NFS filesystem.  This is not useful
!    for a standalone machine, so eliminate the need for extra baggage in kernel. */
! #ifdef NFSCLIENT
! 	extern struct vnodeops nfsv2_vnodeops;
  
  	if (vp->v_op == &nfsv2_vnodeops)
  		vn->sc_maxactive = 2;
  	else
+ #endif
  		vn->sc_maxactive = 8;
  
+ /* dej 27-sep-93: This is dead code!  maxactive is either 2 or 8 from above. */
+ #ifdef WE_LIKE_DEAD_CODE
  	if (vn->sc_maxactive < 1)
  		vn->sc_maxactive = 1;
+ #endif
  }
  
  vnshutdown()
-- 
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
email: [email-masked], finger for more info

---



> This is noticed since CTRL-^ is the "swap file" command in vi, which

	I'm a little uncomfortable with this fix.  I don't know how
ctrl-6 is "supposed" to work, but I seem to run into more systems where
you have to type shift-ctrl-6 to get ctrl-^ than those that will take
just ctrl-6.  For people's private kernels, well, whatever floats your
boat, but I wouldn't want to see this in the distributed sources.  But
that's just my opinion.  (I'd also like to see mw un-swap BS and DEL
in the keymap, too, so that might give you a clue about my proclivities.)

--
------------------------------------------------------------------------
Andy Heffernan                                            [email-masked]

---



> All fixes are relative to .644 and there are more to come.

Look mostly ok, thanks!

> This is noticed since CTRL-^ is the "swap file" command in vi, which

You say it, CTRL-^ is ..., not CTRL-6. I think it's the correct thing
to force the user to use shift here, there may be keymaps that keep two
valid ctrl-able symbols on one key, and then chosing one of them
arbitrarily would be very bogous.

> This is wasteful on a non-networked machine.

Your remark is true, however, just the mean question: did you get the 
vn driver to work at all? I never tried.. :-) Doesn't it need some special
tool to set up a file so it can be mounted?

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	[email-masked]
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH

---



> just ctrl-6.  For people's private kernels, well, whatever floats your

Agree.

> in the keymap, too, so that might give you a clue about my proclivities.)

Nope.. we're supposed to be a vt100/200 or something similar, and I just
hate to land in help mode when working with emacs. 

Besides: there's support for loading custom keymaps, I just think it's
not yet working.. people that would like such support (foreign keymaps?
swapped back bs/del?) would you care to take a look at it? The command
to load keymaps is in amiga/stand, called loadkmap).

-Markus

---



> hate to land in help mode when working with emacs. 

	I wasn't really looking for a response, but in my opinion a
keyboard that generates DEL when you hit backspace (and vice versa) is
broken.

	At any rate, generations to come will be struggling over this
Stallman mistake.  I hate the "delete deletes but backspace invokes
help" problem as well, but find it a bit unsavory to work around an
application's brain-deadedness by dinking in the kernel, or device
drivers, or whatever.  I have to deal with this on other systems as
well, so I put this into my .emacs everywhere and forget about it:

;
; There must be a better way to do this...
;
(cond
 ((eq help-char ?\C-h)
  (define-key help-map "\C-^" (lookup-key help-map "\C-h"))
  (define-key help-map "\C-h" (lookup-key help-map "\177"))
  (define-key global-map "\C-^" (lookup-key global-map "\C-h"))
  (define-key global-map "\C-h" (lookup-key global-map "\177"))
  (define-key c-mode-map "\C-^" (lookup-key c-mode-map "\C-h"))
  (define-key c-mode-map "\M-\C-^" (lookup-key c-mode-map "\M-\C-h"))
  (define-key c-mode-map "\C-h" (lookup-key c-mode-map "\177"))
  (define-key c-mode-map "\M-\C-h" (lookup-key c-mode-map "\M-\177"))
  (define-key lisp-mode-map "\C-^" (lookup-key lisp-mode-map "\C-h"))
  (define-key lisp-mode-map "\C-h" (lookup-key lisp-mode-map "\177"))
  (define-key esc-map "\C-^" (lookup-key esc-map "\C-h"))
  (define-key esc-map "\C-h" (lookup-key esc-map "\177"))
  (setq search-delete-char ?\C-h)
  (setq help-char ?\C-^)))

	Custom, site-loadable keymaps are a better solution, however.

---



> arbitrarily would be very bogous.

There are only 32 "control" characters, not counting meta-thingies.

CTRL-A thru CTRL-Z are 26 of them.  The remainder:

ASCII 0 is often CTRL-@ which is CTRL-2.
ASCII 27 is CTRL-[ (ESC).
ASCII 28 is CTRL-\.
ASCII 29 is CTRL-].
ASCII 30 is CTRL-^, which is CTRL-6.
ASCII 31 is CTRL-_, which is CTRL--.

Except for @, ^ and _, all of the "controllable" characters can be typed
w/o the shift key.  The unshifted versions, 2, 6 and - are not "controllable".
For this reason, there is no loss of functionality to not require the shift
key for these keys.  You lose nothing, and gain an extra finger :-)

A better fix for this problem would be to look in the unshifted keymap,
and not finding a controllable key, look in the shifted keymap.  This is
keymap-independent to a certain extent too.  I will implement this and send you
the patch.

> tool to set up a file so it can be mounted?

I don't know.  I don't really care.  I have 4MB of RAM on my system and I feel
that I have better uses for this RAM than NFS.  So I took NFS out of my config
and vn.c puked.  That's all I was trying to fix.

---



>>>>> "Andy" == Andy Heffernan <[email-masked]> writes:

Andy> 	I wasn't really looking for a response, but in my opinion a
Andy> keyboard that generates DEL when you hit backspace (and vice
Andy> versa) is broken.

Hmm... What's at the top of a delete keycap?  Of a backspace Keycap?  Some of
you will answer "DEL" & "a left arrow" respectively, others will say "a left
arrow" & "BS", respectively.  You see the  problem?  A left arrow key could
be anything.

Andy> 	At any rate, generations to come will be struggling over this
Andy> Stallman mistake.

It's not a mistake, just different opinions.  I used to think like you, until
we started to use the vt[123]?0 line of terminals some years ago.  Now, as
any sane mind, I only curse non-customizable programs.  They're the ones
which should be haunted, not Stallman or some left-arrow-is-of-course-
backspace dude.  Customization, as always, is the only tie-breaker.

Niklas

Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: [email-masked]
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas

---



> arrow" & "BS", respectively.  You see the  problem?  A left arrow key could

Nope; it's "DEL" and "H". Left arrows aren't trustworthy :-). Of
course, labels don't mean a thing for people who touch-type; it's
where the keys are.

> Customization, as always, is the only tie-breaker.

So you get things like my Sun "Unix Locale" type 5 keyboard, where the
unlabelled keycap sends escape, the "ESC" key sends "~" or "`", the
"~"/"`" key sends C-H, and the "Backspace" and "Delete" keys send
"DEL".

	<mike