Re: About support for rtVAX300

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> *(int *)vax_map_physmem(0x201ffffc,1)=(int)(0xf-7)<<16;

Shouldn't that be

((int *)vax_map_physmem(0x201ffffc&~511,1))[(0x201ffffc&511)/sizeof(int)] = ...

?  Or, likely, a mask appropriate to whatever NetBSD's software
pagesize is on the VAX, rather than 511?  (I think NetBSD has used a
larger pagesize than the hardware for quite a while.)  See below.

>        0x800002bc                Xtransl_v
> ...Translation invalid or something..

Translation not valid fault, I think it is (perhaps abbreviated by the
code that prints it).

> [...] what could be wrong with that vax_map_physmem() call?

My remarks above are based on the assumption that vax_map_physmem deals
with page-aligned values, which 0x201ffffc isn't.  What I wrote above
page-aligns the argument to vax_map_physmem and then offsets from the
result appropriately.  (The division by sizeof(int) inside the
subscript is because the returned pointer is cast to int *; C
subscripting works in units of the pointed-to type.  It could also work
to do

*(int *)(((char *)vax_map_physmem(0x201ffffc&~mask,1))+(0x201ffffc&mask)) = ...

(where mask is pagesize-1) instead, that is, compute the address using
pointer-to-char and cast it to pointer-to-int only after that's done.
Which you prefer depends on how you prefer to think of it; they amount
to the same thing.  The version using subscripting does have the
arguable disadvantage that it blindly assumes 0x201ffffc is correctly
aligned for an int.  In VAX-specific code I don't see this as an issue.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B