Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!mwm
From: mwm@ucbvax.BERKELEY.EDU (Mike Meyer)
Newsgroups: mod.computers.68k
Subject: (none)
Message-ID: <8608140504.AA16928@ucbvax.Berkeley.EDU>
Date: Thu, 14-Aug-86 01:04:10 EDT
Article-I.D.: ucbvax.8608140504.AA16928
Posted: Thu Aug 14 01:04:10 1986
Date-Received: Thu, 14-Aug-86 03:40:48 EDT
Organization: The ARPA Internet
Lines: 59
Approved: info-68k@ucbvax.berkeley.edu

Subject: Re: 68020 high address byte useage
Newsgroups: mod.computers.68k
In-Reply-To: <8608060229.AA18573@ORNL-MSR.ARPA>
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada
Cc: 
Bcc: 

In article <8608060229.AA18573@ORNL-MSR.ARPA> Jim Mullens write:
>
>In article <947@hoptoad.UUCP> John Gilmore writes:
>>In article <259@cci632.UUCP>, rb@cci632.UUCP (Rex Ballard) writes:
>>>                                                             ...did you
>>> fix the perverse usage of the high address bits so that a 68010 or 68020
>>> could be used in place of the 68000?
>>
>>This is a red herring.  First, a 68010 has the same address space as a
>>68000.  Second, a 68020 just feeds those bits out on pins; if you have
>>less than 16 megs of stuff to address, you're free to ignore the pins.
>
>Please pardon my breaking in here, but I couldn't resist the
>possibility of learning something about the 68020 by asking a
>question...
>
>My 60820 manual says that virtual memory can be implemented by
>handling the bus error resulting from trying to read a non-physical
>address.  (A bus error is signalled, causing the bus error handler to
>be called, which must eventually result in a page being swapped into
>RAM from secondary storage).  The 68020 manual claims that this
>technique can also be used for the 68010 and the 68012, but doesn't
>mention the 68000.  My 68000 manual simply says that a bus error is
>not likely to be a recoverable error.

True.  Also, most 68020 CPU boards (eg the ones in our products, or Motorola
MVME131's etc.) have their device I/O areas and multi-port memory addresses
splattered all over the 32 bit physical address space.  (eg: our multibus
is at 0x12000000, the high speed bus is at 0x80000000-0xffffffff)
Nor can most machines no-op the upper 8 address lines in software....

[BTW: This latter one presents a rather interesting gotcha: Things like
/dev/mem cannot access the upper half of the 68020's address space:
We've tried seeking to 0x80000000, but when the system call checks the
result value (which is <0 signed), this is noted as an error...]

Bus errors on 68000's are not recoverable except by some extremely wierd 
add-on hardware - I can provide details if desired.  68010's and 68020's 
can recover so that they can support virtual memory.

Further, to the guy who said "just ignore the upper 8 bits".  Right.  IBM
has spent tens of millions of dollars trying to get around this type of 
stupidity in OS/360/370 software in an attempt to port to XA hardware
(higher than 16 Mb physical address space machines).  I didn't quite catch
what software the original article was about, but with the upper 8 bits
of the address being random you will not be able to run it on the majority 
of 68020 systems.

Chris Lewis
UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis
Phone: (416)-474-1955