dewolfe@ug.cs.dal.ca (Colin DeWolfe) (01/10/91)
A strange thought hit me today when I was reading the BYTE article on A/UX and about how it's not worth it if you only need UNIX. 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. Granted, I can't figure out why someone would want to, but it would be an interesting thing to try. My first impression is that it would not be possible, sue to my assuming that the kernel bangs directly on the Mac hardware, but it later occured to me that they could be running UNIX as a layer on top of the Mac ROMS (which don't get removed when it is installed). I know that this was done on the C=128 with CP/M (I know, different bag of worms), and I don't see why this can't be done with the Mac. After all, finder is still around and is said to "coexist" with X-Windows, this implies some sort of access to the Mac ROMS. Of course, this is a BIG performance hit, but remember, this is Apple. Just some thoughts.... -- Colin DeWolfe dewolfe@ug.cs.dal.ca
burley@geech.ai.mit.edu (Craig Burley) (01/10/91)
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.eduthad@cup.portal.com (Thad P Floryan) (01/11/91)
dewolfe@ug.cs.dal.ca (Colin DeWolfe) in <1991Jan10.060309.28669@cs.dal.ca>
writes:
A strange thought hit me today when I was reading the BYTE article on
A/UX and about how it's not worth it if you only need UNIX.
True. Members of Apple's A/UX Development Team have asked me, point blank,
in response to my criticisms of A/UX:
"If you didn't want the MacOS, why'd you get A/UX?"
Sounds like Apple has been mis-representing A/UX. We got suckered into
believing they (Apple) would support UNIX on Mac hardware platforms, but such
is not really the case as the January 1991 BYTE article also points out (re:
A/UX being s-o-o-o old (circa 1983)).
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. Granted, I can't figure out why someone would want
to, but it would be an interesting thing to try.
Other than the fact it doesn't operate well with less than 4MB RAM and makes
a lot of assumptions regarding the hardware (i.e. number of serial ports,
expansion cards installed, etc.) and requires a LOT of disk space, this might
be an interesting (but expen$ive) experiment (and not one that I'm going to
underwrite).
My first impression is that it would not be possible, sue to my
assuming that the kernel bangs directly on the Mac hardware, but it
later occured to me that they could be running UNIX as a layer on top
of the Mac ROMS (which don't get removed when it is installed).
This seems to be true, but I haven't studied the A/UX architecture all that
much after my initial disappointment (and I've used all versions from 1.0,1.1,
up to 2.0). At this point I'm just "enduring" it, and I find it best to come
in on a serial or network port just to avoid staring at the brain-damaged
Apple color monitor (glare on screen) and to avoid using the brain-damaged
keyboard (this is the BIG keyboard, with important keys all in wrong places),
and to avoid using a single-button mouse designed for people who cannot walk
and chew gum at the same time. 'Sfunny, I'm using an Amiga as a terminal into
the Mac because I find the Mac user/terminal interface to be so bad! :-)
I know that this was done on the C=128 with CP/M (I know, different bag
of worms), and I don't see why this can't be done with the Mac. After
all, finder is still around and is said to "coexist" with X-Windows,
this implies some sort of access to the Mac ROMS. Of course, this is
a BIG performance hit, but remember, this is Apple.
A/UX is NOT known for its speed, and tries to gobble up humongous amounts of
RAM for use as a RAM-disk to hide the brain-damaged hardware architecture of
Macs (no DMA, no hardware support chips, etc (except, finally, for the Max IIfx
which uses a 6502 for SCSI support)). It very quickly became apparent to me
that a 68020/68881/68851 Mac II running A/UX is a very poor performer compared
to even my 68010/MMU 3B1 systems.
You've obviously read the BYTE article and seen the prices; you'd be MUCH
better off buying a second Amiga with UNIX than to dork-around with A/UX.
Thad Floryan [ thad@cup.portal.com ]dewolfe@ug.cs.dal.ca (Colin DeWolfe) (01/15/91)
In article <37836@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >dewolfe@ug.cs.dal.ca (Colin DeWolfe) in <1991Jan10.060309.28669@cs.dal.ca> >writes: > > A strange thought hit me today when I was reading the BYTE article on > A/UX and about how it's not worth it if you only need UNIX. > > >Other than the fact it doesn't operate well with less than 4MB RAM and makes >a lot of assumptions regarding the hardware (i.e. number of serial ports, >expansion cards installed, etc.) and requires a LOT of disk space, this might >be an interesting (but expen$ive) experiment (and not one that I'm going to >underwrite). Don't blame ya. > > > I know that this was done on the C=128 with CP/M (I know, different bag > of worms), and I don't see why this can't be done with the Mac. After > all, finder is still around and is said to "coexist" with X-Windows, > this implies some sort of access to the Mac ROMS. Of course, this is > a BIG performance hit, but remember, this is Apple. > >A/UX is NOT known for its speed, I didn't try to say it was fast, exactly the opposite I find the AUX IIfx I have seen to be barely acceptable ( and that's a 40MHz machine) >and tries to gobble up humongous amounts of >RAM for use as a RAM-disk to hide the brain-damaged hardware architecture of >Macs (no DMA, no hardware support chips, etc (except, finally, for the Max IIfx >which uses a 6502 for SCSI support)). They use a 6502 for SCSI support? My god that's horrible... I haven't seen one of those since the C64, except for the IIgs (which some one by the way thinks it can run UNIX) (I almost keeled over in a laughing fit when I saw my newsreader prompt me if I wanted to add comp.unix.appleiigs to my newsrc) >It very quickly became apparent to me >that a 68020/68881/68851 Mac II running A/UX is a very poor performer compared >to even my 68010/MMU 3B1 systems. > They have one at the local Apple dealer (Atlantis) which is owned by the same person who owns one of the Amiga dealerships (Kobetek) He seems to be pinning his UNIX hopes on the Mac and won't even consider ordering in a A3000UX, even though it is better. He even told me he might not order UNIX for my 3000 when it is available. What a schmuck!!! I bought the machine in his shop and he won;t even sell me UNIX. Needless, I now frequent (and even work for now) the other dealer. (They needed a UNIX familiar person, in case they decide to get a 3000UX) > >You've obviously read the BYTE article and seen the prices; And I lauged my head off. >you'd be MUCH >better off buying a second Amiga with UNIX than to dork-around with A/UX. > Don't worry, that's what I got my 3000 for, along with the speeeeeeeed. It was more academic curiosity than anything else. >Thad Floryan [ thad@cup.portal.com ]
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/16/91)
In article <1991Jan15.052135.16104@cs.dal.ca> dewolfe@ug.cs.dal.ca (Colin DeWolfe) writes: >>Macs (no DMA, no hardware support chips, etc (except, finally, for the Max IIfx >>which uses a 6502 for SCSI support)). > >They use a 6502 for SCSI support? My god that's horrible... I haven't >seen one of those since the C64, except for the IIgs (which some one by the >way thinks it can run UNIX) (I almost keeled over in a laughing fit when I >saw my newsreader prompt me if I wanted to add comp.unix.appleiigs to >my newsrc) Is this true with UNIX on that machine? Can't believe it. But with the 6502 in the Mac IIfx, it's another story. They even have two of them as intelligent peripheral controllers, running at 10 MHz. Boy, when I imagine my old PET at tenfold speed, I almost could forget about my Amiga! (Ehm, almost :-) But when I am informed correctly, those 6502s are not normal chips, but they are buried as parts of bigger ASIC chips. So obviously you can use the 6502 as a ready building block for your gate arrays or ASIC chips. So let's dream of a Connection machine built out of 64 K 6502 chips or something else wonderful... -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
6600prao@ucsbuxa.ucsb.edu (Parik Rao) (01/16/91)
the IIgs uses a 65816, a 16 bit cpu that can readily emulate the 6502. There is no unix for that system. Just as a factoid; the Super Famicom uses a 65816 also (the "super nintendo / nintendo sfx"). Wouldn't that be interesting... a amiga 500 emulating a nintendo, sega genesis, turbographix, lynx, IBM, amiga, mac, Apple IIgs... and then blow past everyone with a a3000...:) -- Parik Rao, University of California Santa Barbara 6600prao@ucsbuxa.ucsb.edu
pashdown@javelin.es.com (Pete Ashdown) (01/18/91)
kawakami@tornado.Berkeley.EDU (John Kawakami) writes: >In respose to the "no-board" emulator advocate: a board with a 6502 on it >would be the best way to emulate an AppleII (or C64 or Atari 800 or PET >or any 6502 machine.) There is a lot of overhead involved in emulating >the instruction set, so you save lots of time and effort. Plus, you get >better compatibility with software. If you run the processor >at 4Mhz, it will run faster than the original host machines. I assume this was in response to my jab about Apple requiring a card to emulate a //e on a 20 mhz Mac SI. The processor on the board would make sense if you were to be running the emulator in a window. However, as I understand it, the emulator on the SI takes over the machine. -- "No, no, no! It is an empirical law of physics that the heat flux at any point is proportional to the temperature gradient at that point." - Claudia Schiffer, over breakfast. Pete Ashdown pashdown@javelin.sim.es.com ...uunet!javelin.sim.es.com!pashdown
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/18/91)
In article <1991Jan17.182428.4269@javelin.es.com> pashdown@javelin.sim.es.com writes: >I assume this was in response to my jab about Apple requiring a card to >emulate a //e on a 20 mhz Mac SI. The processor on the board would make >sense if you were to be running the emulator in a window. However, as I >understand it, the emulator on the SI takes over the machine. The emulation board is for the Mac LC. The processor is a 16Mhz 020. The board does take over the machine when you're running emulation (stupid idea Apple came up with, there.) There is an Apple II emulator that will run on any Mac Plus and up machine.