Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.misc
Subject: Re: Mac emulating Amiga
Message-ID: <20894@cbmvax.commodore.com>
Date: 23 Apr 91 22:49:25 GMT
References: <9104012131.AA03364@covax.co.iup.edu> <1991Apr2.000456.26982@cunixf.cc.columbia.edu> <2864@borg.cs.unc.edu>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 57

In article <2864@borg.cs.unc.edu> tell@oscar.cs.unc.edu (Stephen Tell) writes:
>In article <1991Apr2.000456.26982@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes:
>>In article <9104012131.AA03364@covax.co.iup.edu> student@COVAX.CO.IUP.EDU (student) writes:

>>Although >programs that directly access the hardware, even legally, on the
>>Amiga will crash on a Mac->Amiga emulator, any programs which legally call 
>>the system can have hardware access "emulated", although I can't account 
>>for the speed.

>If the writers of an emulator wanted to, they could emulate the hardware
>exactly.  Just use the MMU to trap accesses to the addresses of the
>custom chips, then when such a trap comes in figure out what custom
>chip register was accessed and simulate the register in software.

That's certainly possible, although extremely slow, if all you're attempting
to emulate is the register level behavior of certain classes of hardware
devices.  Most of this wouldn't be required to run the Amiga OS on a Mac,
since you could supply keyboard, hard disk, mouse, etc. drivers for these
resources that know about the Mac equivalents.  You would, however, get in
trouble, for example, if the Mac equivalents couldn't generate interrupts,
or dealing with Mac floppy transfers (the entire system would have to block
during floppy access, since there's no floppy DMA on a Mac).  Using traps
might let you deal with the small class of programs (eg, games) that directly
access this hardware.  But that's just the beginning of your problems.

Next comes directly poked sprites.  A hardware trap via MMU would be required
to simulate sprites.  But it'll be far too slow to model the realtime behavior
most video type games expect out of their sprites.  Not to mention collision
detection.  Similarly, blitter activity could be emulated via traps, and even
around as fast as the real blitter on an '020 or '030 system.  But keep in
mind that the actual blitter rendering is not happening to screen memory.  Why?
Because the Amiga is bitplane oriented, while color Macs use packed pixels.
So every screen write would happen to shadow memory, then get converted to
packed pixels and actually drawn to the Mac's display memory.  That's what you
call slow.

Next we get to impossible.  That's the Copper.  An independent, parallel 
display list processor.  If the Mac can't generate interrupts when video beam
counter gets to a prespecified X,Y position on screen, it can't begin to
emulate the Copper's WAIT instruction, even in software.

>I believe the correct term for this idea is a "virtual machine."  You appear
>to have hardware, but you really don't.  

True, but when folks speak of virtual machine, like in the IBM context, that's
not generally talking about hardware.  The concept here is that an operating
system, which normally expects to run in kernel/supervisor mode, can be tricked
by the real operating system into thinking its in kernel mode, when in fact it
is a user mode application running under some other real kernel.  This is not
only useful for IBM's tricks, but for when you're cross-developing one OS on 
a machine with a different OS.  

>Steve Tell       tell@cs.unc.edu    H: +1 919 968 1792   #5L Estes Park apts
-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      "That's me in the corner, that's me in the spotlight" -R.E.M.