[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[wes.parish@paradise.net.nz (Wesley Parish)]

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
>