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. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.126.238.100