NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/emulatia/5661

Internet Message Format | 1992-12-29 | 3.6 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!ogicse!pdxgate!parsely!percy!cryo!jdrew
From: [e-mail] (Jim Drew)
Newsgroups: comp.sys.amiga.emulations
Subject: Re: EMPLANT for 1200?
Message-ID: <[e-mail]>
Date: 29 Dec 92 17:33:00 GMT
Article-I.D.: cryo.jdrew.0mhi
References: <[e-mail]>
Organization: Cryogenic Software - Portland, OR USA
Lines: 61
X-NewsSoftware: BBX-UMB 0.27 beta (Nov 22 1992)


In <[e-mail]>, [e-mail] (Robertc. Moldenhauer) writes:
>
> Yes, my Emplant boots quite nicely from an AMAX partition, in colour too!  I
> thinkk we were all too quick to jump on jim when the original software came
> out.  But I do have a couple questions.
>
> 1) I have a 2000 with a 2620, while I realise this is slow for a 1992/3 machine
> Emplant seems to crawl relative to AMAX, even with the priority kicked up.. Why
> is it so slow?  I mean it takes seconds even for the menus to open!
>
> 2) When will there be support for all memory, not just 32 bit?
>

You have to remember that the MAC we are emulating is a MAC II/x/cx.
These MACs use 256K ROMs and have a substantial amount of system overhead
(read as slow down) due to the new features added over the MAC+.  The MAC
II is a 15.66Mhz 68020 and it runs only about 5-10% faster than a 8Mhz
68000 based MAC+.

You really only want to use 32 bit memory with the MAC emulation.  MACs
only have 32 bit memory (systems higher than the MAC+).  If you have 32
bit memory and an MMU, tests done with Speedometer (PD MAC equiv of the
Amiga's AIBB) show that our emulation is the same speed or within 3% of
the speed of AMAX, all while multitasking (tests conducted with the same
Amiga using AMAX and EMPLANT).

The way that the MAC emulation works requires the multi-tasking to be
functioning.  A seperate task updates the video display.  A seperate task
handles the device support, the ADB, and another task handles the
emulation itself (ran in SuperVisor mode).  Raising the priority higher
than 0 has _no_ real advantage.  This because one task will be steal more
time for the others, and some of the tasks' priorities can not be higher
than others (or higher than many pre-existing tasks).

We use the keyboard.device to fetch the keyboard data.  We were going to
go straight to the CIA, however, when a level 2 interrupt is generated by
the CIA and the keyboard matrix value is read, the interrupt goes away.
This means that if the MAC emulation read the CIA (instead of the
keyboard.device) the Amiga would never know that a key was pressed.

Although we could re-write the emulator to take over the entire system
(like AMAX) I refuse to do it.  We do not lose that much speed compared
to AMAX (especially when you realize that we are only taking about 50%
total CPU time while multi-tasking).

Our biggest slowdown is the video.  Having to convert a entire MAC screen
into Amiga planar data is terribly slow, even though that we write
everything in _highly_ optimized assembly code.  Actually, comparing a
page is where the slow down really shows.  A 16 color hires screen takes
384,000 clock cycles just to compare a single page.   We have nifty new
routines that now use the MMU to flag changes in the video pages.  Using
the MMU reduces the number of clock cycles to just a few hundred, many
thousands of times faster than before.  Real time video is now possible
with the Amiga video.


Jim Drew - Vice President, Utilities Unlimited, Inc.
           1641 McCulloch Blvd. Suite #25-124
           Lake Havasu City, AZ  86403
           [phone]     [phone] FAX    [phone] BBS