> All except for hp300, which is called m68k4k due to it's pagesize of
> 4K instead of 8K.  I don't understand why noone has done emulation for
> these incompatibilities though...  We could just specialcase the
> boundaries or just skip demand-paging and load the lot unprotected.
> It should be doable, no?  Someone (Theo?) suggested this to me when I
> asked about the possibilities of doing a NCR tower32 emulation and it
> seems simple enough to me.

as a matter of fact, to my left i am running a machine with NBPG of
4096, but it uses an __LDPGSZ of 8192. therefore it will run amiga
binaries. i ran them for a long time. but it has small pages.

it's pretty trivial to change the hp300 port to that. you change
__LDPGSZ in the hp300 tree to be 8192 (it is 4096 now). next, compile
the whole world. now the problem: you worry about how you're going to
get the new binaries onto the disk without confusing the system! ;-)

there's a bit more to it. to do a really nice job, you want to support
old MID_M68K4K binaries on the hp300: they need to load at 4K, not at
8K (the symbol for that is USRTEXT); also you should ensure that the
data segment rounds to a 4K boundary, not 8K. the easiest way to
handle that is to simply copy & hack the exec_aout_prep_{o,n,z}magic()
functions and make the hp300's cpu_exec_aout_makecmds() function call
those.  anyone who is interested can read the last 100 lines or so of
hp300/machdep.c (there might be enough there that some industrious
person could do it.)

> Perhaps I'm just mistaken, and we already can emulate criss/cross
> m68k/m68k4k binaries...

i haven't seen any code to do it in the tree. i wrote some changes for
Herb more than a year ago. but they didn't work and i never finished
debugging it. (i must have made some stupid rounding error).

attempting to run m68k4k binaries on 8K NBPG machines (ie. amiga)
would be really nasty. first, you'd have to load the text segment at
4K which means that *NULL would actually have to work -- yuck!
secondly, as a result of the text/data segment boundary rounding to
4K, there's a 50% chance that you would need to write-enable the last
4K of the text segment.... simply nasty.

by the way, in that recent discussion about pmap problems
(ie. clearing mem, *NULL in kernel, etc) was any concensus reached? i
have been fighting the same bug/bugs for a while myself, and have had
to impliment similar workarounds.