Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!sri-unix!jcp@BRL-TGR.ARPA From: jcp@BRL-TGR.ARPA Newsgroups: net.micro Subject: Re: The 68010 and MMU's Message-ID: <1999@sri-arpa.UUCP> Date: Fri, 20-Jul-84 01:20:47 EDT Article-I.D.: sri-arpa.1999 Posted: Fri Jul 20 01:20:47 1984 Date-Received: Tue, 17-Jul-84 01:10:12 EDT Lines: 25 From: Joe Pistritto The 68451 certainly does exist and is available, (although not in massive quantities). The only format i have seen it in is the square LCC package though. In particular, more than one can be used at a time, and Omnibyte Corp. of Chicago makes a board called OB68K/MMU or something like that which has a 68010 with one to four 68451s on board. By the way, the types of memory management provided by the 68010 and the 68451 are DIFFERENT, the 68010 is for VIRTUAL memory implementations, (and by itself is used in the Sun processor, with custom memory management hardware), and the 68451 performs MEMORY RELOCATION only. The one thing you do need to do is always use a 68010 in ANY scheme that does dynamic memory management, (to wit, most UNIX implementations), as the 68000 has unrecoverable faults when a bus-error occurrs. (Not enough of the internal state of the CPU is accessable to re-run the bad instruction) The most ANNOYING thing is that the address pushed on the stack by the exception is NOT always the address of the bad instruction, (or the next instruction), it seems to be the pre-fetch pointer for the instruction pipeline, which can be in the middle of a DIFFERENT instruction from the one which caused the trap. BELIEVE ME, I tried for a couple of weeks to enable a 68000 based system to recover from faults, its NOT possible easily, anyway... -JCP-