Article View: mod.computers.68k
Article #86(none)
From: Mike Meyer
Date: Thu, 14 Aug 1986 05:04
Date: Thu, 14 Aug 1986 05:04
58 lines
3470 bytes
3470 bytes
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
Technical Details
Message-ID:
<8608140504.AA16928@ucbvax.Berkeley.EDU>Path:
arc1-ca.pugleaf.net!utzoo!decvax!ucbvax!mwmShow Full Headers
Complete Article Headers
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: arc1-ca.pugleaf.net!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