The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Arno Griffioen <arno.griffioen@ieee.org>
To: tuhs@tuhs.org
Subject: Re: [TUHS] Historical sources for 68010 + 68451 systems?
Date: Wed, 16 Sep 2020 07:21:49 +0200	[thread overview]
Message-ID: <20200916052149.GH3311@ancienthardware.org> (raw)
In-Reply-To: <DFA6E8C5-FA9A-42AA-B46C-289E373E053A@eschatologist.net>

On Tue, Sep 15, 2020 at 04:28:36PM -0700, Chris Hanson wrote:
> I have an MVME121 that I’d like to run some stuff on. I’m planning what I’ll 
> need to do to port MINIX 1.5 but since this has a 68451 segmented MMU, I’d 
> like to actually make use of it.

Quite doable to adapt MINIX to this. Did a similar thing ages ago while 
still in school on a 68010 machine (not really VME, but similar card-cage
setup) that had a custom MMU built from some SRAM and some control logic on 
it. Used MINIX 1.1 at the time though..

Only had 1MB physical RAM and the MMU could provide a virtual address space 
of 4MB.

Initially ported MINIX to the machine 'as is' from the ST version and then
modified the MINIX kernel to allow it to use the 4MB virtual space and
such.

Because of the bare-bones MMU design it had some interesting quirks that made 
it a good learning experience at the time. (and some very odd serial chips
for the terminals that had their own 'interesting' behaviour but that's
a different story..)

Originally the machine did have a real SVR2 UNIX running on it, but sadly it 
was binary-only, so apart from some dis-assembly of bootstrap bits to learn
how to get MINIX to start on this machine it was not very useful.

> I figure at minimum I could have several segments set up to enforce 
> protections and a stable per-process address space, but it’d be good to 
> have an example.

Yup. You may run into some of the shortcuts in the MINIX kernel when you start
doing MMU work though, especially if you want to separate the kernel
'processes' as well. 

For performance the microkernel architecture of MINIX was violated in a few 
spots, mostly around FS and MM, where one kernel process would/could modify
another's memory without going through the message passing mechanism.

Introduce an MMU and that kinda breaks and needs some cleaning up ;)

As MINIX later on did get a 386 port and cleanups/fixes that may now be a
non-issue on 1.5.

Another option would be Linux/m68k and perhaps starting on the 'nommu'
version that runs on basic 68000's too and seeing how much functionality could 
be used from the 68451 to enhance it. 

Some of the Coldfire CPU's have similar limited MMU's that are supported for 
some functions of basic memory protection in the 'nommu' tree.

As far as real UNIX sources go.. SUN2's were 68010's too although AFAIK
with a custom SUN designed MMU logic? Perhaps some old sources available in 
that corner though.

							Bye, Arno.

  parent reply	other threads:[~2020-09-16  5:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 23:28 Chris Hanson
2020-09-15 23:55 ` Gregg Levine
2020-09-16  3:05   ` Chris Hanson
2020-09-16  5:21 ` Arno Griffioen [this message]
2020-09-16  8:53 ` Al Kossow
2020-09-16 23:47   ` Dave Horsfall
2020-09-16 19:53 Nelson H. F. Beebe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200916052149.GH3311@ancienthardware.org \
    --to=arno.griffioen@ieee.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).