Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!snorkelwacker.mit.edu!ai-lab!life!burley From: burley@geech.ai.mit.edu (Craig Burley) Newsgroups: comp.sys.amiga.emulations Subject: Re: A/UX on AMAX Message-ID: Date: 10 Jan 91 13:59:48 GMT References: <1991Jan10.060309.28669@cs.dal.ca> Sender: news@ai.mit.edu Distribution: na Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 (617) 253-8568 Lines: 48 In-reply-to: dewolfe@ug.cs.dal.ca's message of 10 Jan 91 06:03:09 GMT In article <1991Jan10.060309.28669@cs.dal.ca> dewolfe@ug.cs.dal.ca (Colin DeWolfe) writes: This thought (which is mine, and what it is too (old Monty Python joke)), was whether it would be possible to somehow run A\UX on the AMAXII emulator. I'd be very surprised if this was true. The Mac OS and its user programs all run in supervisor mode (or whatever the 680x0 family calls it), which means they have full access to the hardware. However, the user programs rarely use the instructions that are inaccessible in user mode, instead they use trap instructions to call on OS system services, primarily in ROM, such as QuickDraw. Moreover, nothing in the Mac OS or its user programs (yet) makes use of the virtual memory capabilities of the 680x0 series (68020 with PMMU and the 68030). AMAXII, I believe, creates an environment where Mac applications run in supervisor mode (or they run them in user mode and emulate all the weird instructions they care to) and where the traps invoke the same (or similar) Mac code as they do on a Mac, rather than AmigaDOS code. But AMAXII probably couldn't handle an OS other than the normal Mac OS taking over, or trying to take over, the whole system as far as doing virtual memory (which A/UX requires -- it doesn't run on 68000s, for example), in that it probably doesn't emulate the low-level Mac facilities A/UX expects to be able to access directly instead of via traps to the OS as done by normal Mac applications. It would be an interesting thing to test, nevertheless. I recommend trying something simpler first: emulate a Mac with Virtual installed. Virtual is the INIT that provides a virtual-memory environment in the Mac OS, allowing a 68030/68020+PMMU user with, say, only 4MB, to have up to, I think, 14MB of virtual memory. Apparently Virtual works (i.e. does not fail) with many Mac apps, but not all of them; whether it really works (performs adequately) is another question, because virtual memory is not just an OS/hardware issue, but its presence or absence should greatly influence the way speed-sensitive programs are coded (and most GUI stuff should be speed-sensitive). For example, a text editor can get away with big shuffles (shifting large portions of text a short distance to make room for new text) on non-VM systems that are basically fast enough, and that might well be, overall, the most efficient approach (when including issues like code size, important on non-VM systems). However, on a VM machine, such a shuffle is likely to incur many page faults, which requires disk accesses, which is much slower, so editors designed to work on VM machines have more code (like GNU Emacs) to handle an internal representation of text that has less overall tendency to access many pages when doing simple operations. If Virtual works under AMAXII, it still is not likely to indicate that A/UX will work, but if Virtual doesn't, then A/UX probably won't. -- James Craig Burley, Software Craftsperson burley@ai.mit.edu