Mini vMac v3.2.1 Alpha (2010-09-12) - 模擬器

http://minivmac.sourceforge.net/

Mini vMac v3.2.1 Alpha (2010-09-12) is released.Mini-vMac is a Macintosh
Plus, Macintosh SE, Macintosh 128 and Macintosh 512 emulator. Mini vMac
emulates a Macintosh Plus, one of the earliest of Macintosh computers. It can
run old Macintosh software that otherwise couldn't be used on recent
machines.

Mini vMac v3.2.1 Alpha (2010-09-12) Changelog:


Today's Mini vMac 3.2.1 alpha is the netbook edition of Mini vMac. It also
includes work on better accuracy of speed. This is an alpha, rather than a
development snapshot, mainly to help ensure the development version doesn't
drift too far from shippable.

Thanks in part to donations from Zebadiah Kimmel and Greg Lee, I now have an
ASUS netbook. Using it as one of my primary computers will encourage better
support for Windows and Linux. It is a different experience from briefly
using them in VMware Fusion. (The model of Mac Mini I was thinking of getting
was discontinued, the new model is more expensive, and I can get most of the
desired benefits of enabling 64 bit development for much cheaper with the
netbook.)

The first improvement I've made for the netbook is auto scrolling. If the
emulated screen is larger than the real screen while in full screen mode, the
emulated screen will be scrolled to keep the mouse pointer in view.
(Previously only the top left corner would ever be displayed.)

The other improvement I've made so far because of the netbook is an
"AutoSlow" feature to help conserve the battery. If the user hasn't typed, or
clicked, or moved the mouse, and the emulated computer hasn't drawn to the
screen, for about two seconds, then Mini vMac will automatically shift down
to 1x speed.

A blinking insertion point will not prevent AutoSlow. This required improving
the code for detecting how much of the screen was changed. Previously it
would detect that areas at the top and bottom of the emulated screen hadn't
changed, to limit the amount of drawing to the real screen. Now it can detect
that areas at the left and right of the emulated screen haven't changed. If
the remaining area that has changed is only a single pixel wide and less than
32 pixels tall, it is assumed to be only a blinking insertion point.

It is possible that some software will not draw anything to the screen for
more than two seconds while doing real work, so the AutoSlow feature can be
disabled with Control-S-W.

The biggest changes since the last snapshot are not related to the netbook,
but about improved accuracy of timing. Mini vMac now measures time in cycles
rather than instructions executed. In the simplest form, all instructions are
assumed to take the same number of cycles, and this closely matches the
results of previous versions of Mini vMac. (Mini vMac actually counts sixty
fourth cycles, not just integer number of cycles, so that average times of
instructions can be more accurate.)

But by default, Mini vMac now assigns an average number of cycles for each of
the 65536 primary opcodes. The larger table now used, as of the last
snapshot, for the primary opcodes provides a convenient place to store this,
allowing the more accurate timing to be done fairly cheaply.

As a compile time option, in addition to using the table, Mini vMac can try
to compute more accurate cycles for certain instructions, depending on the
current data. This is slower, and only implemented in the C version of the
68000 emulation, making it slower still. By the way, I believe the MESS
emulator takes this approach.

The build system option "-ta 0" selects the least accurate of these three
methods, the default is "-ta 1", and "-ta 2" selects the most accurate.

Completely accurate timing would be exceedingly difficult. The CPU and video
output conflict for accesses to RAM, and that would seem very complex to
model.

The greater accuracy is so far mostly theoretical. The timings were entered
from Motorola documentation. It needs to be tested and calibrated by
comparing to real hardware.

Currently 68000 timings are used even in the 68020 emulation. More accurate
timing for 68020 should be added in a future version. Truly accurate timing
for 68020 would be much more difficult than for the 68000 because of
pipelining and caching, probably to the point of being unfeasible for Mini
vMac. But more accurate averages should be possible.

Sourceforge has improved, but on second thought it's still not ideal for
releasing large number of files. So I've decided to bring back the Mini vMac
Variations service for distributing compiled variations of this alpha. People
who have previously purchased the Variations can use the activation code they
already have.

If one in ten users of Mini vMac purchased the Variations (for $5), that
would be more than enough to support full time development of Mini vMac,
rather than the current slow pace. But, more realistically, it might
eventually at least pay for the web hosting costs.

--