Disk ][ Launcher (was: Late night musings...)

[nathan@visi.com (Nathan Mates)]

In article <hu83860@pro-palmtree.cts.com>,
Richard Der <rder@pro-palmtree.cts.com> wrote:
>nparker@cie-2.uoregon.edu (Neil Parker) wrote:
>>You can't just emulate one piece of hardware--you have to emulate
>>the *whole* *computer*.  That's how the Apple II emulators on the
>>PC and Mac work--they emulate the processor itself, and all the
>>hardware connected to it.

>>This is a lot of work, and it takes a pretty hefty host processor
>>to do it at a reasonable speed.  An Apple II emulator running on
>>an Apple II is probably possible, but I doubt you'd want to use
>>it--it would almost certainly run many times slower than a real
>>Apple II.

   Quite true. My comments earlier about software acting like hardware
on an Apple II being impossible was only considering anything running
at full speed. With an emulator, it'd be dog slow (assuming all
instructions are verified that they're not memory references, that's
probably about 4 or 5:1 overhead at best. A darn fast (tm) Zip or TWGS
might be able to pull it off, but until someone actually implements
such a beast, numbers are only best guesses.

   Unfortunately, the 5.25" disk controller must be accessed at 32
1Mhz cycles. Given that the GS has hardware to automatically slow
the system down to 1Mhz on accesses to that controller (I'm not sure,
but I really doubt there's any way to disable that), that means that
emulating 5.25" disk accesses would be essentially impossible without
a heck of a lot of logic to figure out that it was a disk access loop,
and use the emulator's version of it.
 
>Would an Apple II emulator running on an Apple IIGS have an advantage
>in that a real 65816 is present? I've noticed that Mac emulators on
>the Amiga don't have much of a performance hit. They seem to consist
>of an image of the Mac ROMs (or the real ROMs in hardware, some
>work with either), and use the actual 680x0 to crunch program code,
>with some fancy programming to reroute Mac hardware accesses to
>Amiga hardware access. The Amiga series is are 680x0 based computers.

   Two words: memory protection. The 68020 (with the external MMU
chip) and the 68030 and up (and possibly also the original Amiga, if
such functionality was built in. I've never used an Amiga or looked at
all its tech specs) allow memory references to certain pages in memory
to cause an interrupt and something special to happen.

   This is normally used for things like automatic swapping if the OS
supports it, memory protection (to prevent programs from stomping on
another), and other fun tricks. What I'd bet the Mac emulators for the
Amiga do is run the code at full speed, but have the mac "hardware"
memory protected. That way, only when the hardware is hit does the
emulator take over and do something special.

   The GS has none of that functionality, so the only way to really
see if an instruction will cause a reference to the "hardware" (Cxxx,
plus the currently displayed screen if you're not running the code in
a bank that is displaying the screen) is to verify each and every
instruction. Anything involving only registers would be simple--- see
if it won't trigger a memory access, and go on from there. Anything
hitting an arbitrary memory address would hhave to have that address
checked to see if it'll cause a hit on hardware, and specially
processed if so.

   About the only thing that an Apple // emulator for a GS could pull
off without much work (writing such a beast for a //e or //c would be
hellacious at best, and they barely would have the processor speed to
do so anyhow) natively is the support of the internal sound and video
systems. Other emulators have to do that also, but the GS can do that
trivially.

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places?  -R.A. Heinlein