I have finally been able to get my NetBSD kernel working to the extent
that I have been able to get the diffs required to make the clock driver
behave in an approximately reasonable manner.   The diffs are shown below.
Note the bogosity of the div by 4 comment.   I'm not sure that the offsets
are exactly right - I haven't looked at TFM on the clock chip recently.
However, switching between NetBSD and Ultrix, both now see the same time,
and either can set the clock without screwing over the other.

*** ../../../../sys-old/arch/pmax/pmax/clock.c	Mon May 30 04:08:12 1994
--- clock.c	Mon Sep  5 22:23:50 1994
***************
*** 130,136 ****
  	min = c->min;
  	hour = c->hour;
! 	day = c->day;
  	mon = c->mon;
! 	year = c->year + 20; /* must be multiple of 4 because chip knows leap */
  	splx(s);
  
--- 130,136 ----
  	min = c->min;
  	hour = c->hour;
! 	day = c->day + 1;
  	mon = c->mon;
! 	year = c->year + 22; /* must be multiple of 4 because chip knows leap */
  	splx(s);
  
***************
*** 223,229 ****
  	c->min = min;
  	c->hour = hour;
! 	c->day = day;
  	c->mon = mon;
! 	c->year = year - 20; /* must be multiple of 4 because chip knows leap */
  	c->regb = t;
  	MachEmptyWriteBuffer();
--- 223,229 ----
  	c->min = min;
  	c->hour = hour;
! 	c->day = day - 1;
  	c->mon = mon;
! 	c->year = year - 22; /* must be multiple of 4 because chip knows leap */
  	c->regb = t;
  	MachEmptyWriteBuffer();

The reason that I was able to make this work is that I have finally implemented
a (minimal) Smart Frame Buffer (PMAGB-BA or CX Turbo) driver and hacked around
the desktop bus problem I was having, so I'm able to get a reliable interactive
shell.   Perhaps I'll now be able to debug the problem with the serial driver
as well.   My sfb hack is not ready for prime time - I haven't tried to make
it work with X yet, and I made a non-portable change to fb.c.   I'll spend
some time cleaning up this code and moving generic stuff out of specific
drivers (sfb.c is almost identical to cfb.c).

The desktop hack is just that.   The desktop driver hard codes the desktop
IDs of the keyboard and mouse.   Unfortunately, these are assigned dynamically,
so for any hard coding to work is mere happenstance.   The assignment seems to
be deterministic, though - it consistently comes up wrong for me with the old
driver, and probably consistently came up right for Ralph and Rick.   The
solution is to probe the desktop and assign the numbers dynamically.  I'll
get to this when I can if somebody doesn't beat me to it.

I still owe several people bootblocks for the 4.4BSD a.out format.   I'll try
to get those out tomorrow...

				_MelloN_

------------------------------------------------------------------------------