[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')
Wesley Parish
wes.parish at paradise.net.nz
Thu Jun 5 19:17:04 AEST 2014
Which of course raises the question: how did AmigaDOS manage context switches
and the like for its brand of multitasking? I know BYTE explained it in the
early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't
remember the details.
Thanks
Wesley Parish
Quoting Arno Griffioen <arno.griffioen at ieee.org>:
> On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote:
> > Ronald Natalie scripsit:
> >
> > > Still with all it's flaws, on the 286 and later UNIX actually did
> run in
> > > protected mode, something it took ages for DOS/Windows (one can
> argue
> > > backwards compatibility with the early processors) or Apple (no
> excuse
> > > here, the early Macs were 68000's which had protection) to pick up
> upon.
> >
> > The original Mac 128K was a 68000 processor, and IIRC memory
> protection
> > didn't arrive until the 68020.
>
> As mentioned by others the 68010 could, with additional external
> hardware,
> support memory management.
>
> The original 68000 (and 8-bit data bus 68008) did already have the full
> 32
> bit instruction and data support of the complete family, but for MMU use
> it
> lacked one critical feature in the fact that it did not push enough
> page-fault
> information on the stack to re-start an instruction in case of an
> (externally
> signalled) page-fault.
>
> So even if you interfaced external MMU logic then a basic 68000 was
> still in
> trouble when a page fault occurred as it could not 'start over' the
> faulted instruction.
>
> The 68010 added the correct stack frames to be able to restart a
> faulted
> instruction and also added the first small performance enhancement in
> the
> form of a 'loop mode' where the CPU could basically cache a small loop
> and execute this without incurring addtional memory wait cycles.
>
> As a result the '010 was usually used in various *NIX machines of the
> era like some SUN2's and various machines (one-offs or low production)
> from other brands.
>
> Eg. I still have a machine in my collection which is from a small local
>
> production run that utilises an '010 with a custom, but quite
> rudimentary,
> MMU based on some simple logic chips and it used to run SVR2. Very
> slowly
> as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual
>
> memory size of 4 Mbyte.
>
> I did port MINIX to it and added memory management/protection support to
>
> the kernel. Ran a lot faster :)
>
> With the release of the '020 Motorola delivered their own full-blown
> (but
> still external) MMU in the shape of the MC68851
>
> Many non-UNIX '020 based machines of the era did not have the MC68851 on
>
> board at all (eg. most Apples from the time) as it was relatively
> expensive
> and could incur extra memory latency/cycles being an external unit.
>
> With the '030 Motorola finally moved the MMU onto the same die as the
> CPU
> (reducing the latency and cost) and it became more prevalent on more
> platforms (although the cheaper 68EC030 was available without an MMU and
>
> used in many machines)
>
> Bringing this back to UNIX, I used to do some local supporting work at
> CBM for
> the Commodore UNIX'es that were Amiga, and of course M68k based.
>
> The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I
> have
> at home :) ) does have both the MC68851 MMU and the MC68881 FPU and
> these
> were used for a, mostly in-house at CBM, SVR3.2 based UNIX version.
>
> AmigaDOS of course also ran fine on it, but did not use the MMU.
>
> The later, general release, SVR4 UNIX version was desgined to run on
> the
> '030 based A3000UX'es, although it still ran on the '020+MMU cards in
> their
> limited (4Mb) DRAM.
>
> Bye, Arno.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuh s
>
More information about the TUHS
mailing list